From owner-freebsd-arm@freebsd.org Sun Dec 27 08:33:54 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B07CBA4DC35 for ; Sun, 27 Dec 2015 08:33:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (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 74BBD1935 for ; Sun, 27 Dec 2015 08:33:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11574 invoked from network); 27 Dec 2015 08:33:59 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 Dec 2015 08:33:59 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 27 Dec 2015 03:33:50 -0500 (EST) Received: (qmail 16681 invoked from network); 27 Dec 2015 08:33:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 27 Dec 2015 08:33:50 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 44D2EB1E001; Sun, 27 Dec 2015 00:33:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: fyi: 11.0-current rpi2 systat -vmstat shows around 24k interrupts for bcm283x_dw From: Mark Millard In-Reply-To: <85B1DF09-7D67-4031-B1E9-E4754CDC690A@dsl-only.net> Date: Sun, 27 Dec 2015 00:33:50 -0800 Cc: freebsd-arm , Adrian Chadd Content-Transfer-Encoding: quoted-printable Message-Id: <61560100-FB03-4A14-A869-25B1EF818F48@dsl-only.net> References: <0A781C7D-C5F5-4931-AE38-D2FEC0848DCA@dsl-only.net> <85B1DF09-7D67-4031-B1E9-E4754CDC690A@dsl-only.net> To: karl@denninger.net X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2015 08:33:54 -0000 [I've moved the irq17 counts material into a tail section.] On 2015-Dec-26, at Sat Dec 26 23:07:43 UTC 2015 Karl Denninger wrote: > Hmmm... I wonder if this is related to the bcm sound driver going = "mute" > and needing a reboot to recover? I've never plugged anything into the audio jack. The DVI monitor (via = HDMI->DVI cable) is soundless. (I've not wanted any sound from the rpi2 = so far and have done nothing to explicitly try to initiate such = activity.) The numbers are in the same range right after booting. The dmesg -a output shows more information about irq17: > bcm283x_dwcotg0: mem = 0x980000-0x99ffff irq 17 on simplebus0 Booting with just the keyboard on usb (no Ethernet cable, no mouse, = etc.) still shows the same range of figures. Then unplugging the = keyboard while systat -vmstat is still displayed does not change the = range either. Older material showing the large Interrupt rate for bcm283x_dwco(tg0) > On 2015-Dec-26, at 2:55 PM, Adrian Chadd = wrote: >>=20 >> What's teh output of 'vmstat -ia' ? >>=20 >>=20 >> -a >>=20 >=20 > # vmstat -ia > interrupt total rate > 0 0 > irq1: mbox0 9128 0 > irq2: vchiq0 3 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > irq17: bcm283x_dwco 1724827933 36 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > irq24: bcm_dma0 0 0 > irq25: bcm_dma0 0 0 > irq26: bcm_dma0 892 0 > irq27: bcm_dma0 0 0 > irq28: bcm_dma0 0 0 > irq29: bcm_dma0 0 0 > irq30: bcm_dma0 0 0 > irq31: bcm_dma0 0 0 > irq32: bcm_dma0 0 0 > irq33: bcm_dma0 0 0 > irq34: bcm_dma0 0 0 > irq35: bcm_dma0 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > irq57: gpio0 0 0 > irq58: gpio0 0 0 > irq59: gpio0 0 0 > irq60: gpio0 0 0 > irq61: iichb0 0 0 > irq62: spi0 0 0 > 0 0 > 0 0 > irq65: uart0 2253 0 > 0 0 > 0 0 > 0 0 > 0 0 > irq70: sdhci_bcm0 448 0 > 0 0 > irq72: generic_time 0 0 > irq73: generic_time 17291857 2 > 0 0 > irq75: generic_time 0 0 > irq76: ipi 9086219 7 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > . . . very many double zeros omitted . . . > Total 1751218733 24478 >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Dec 27 15:06:48 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4635BA52806 for ; Sun, 27 Dec 2015 15:06:48 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E069A1F29 for ; Sun, 27 Dec 2015 15:06:47 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 7982C229DC5 for ; Sun, 27 Dec 2015 09:06:44 -0600 (CST) Subject: Re: fyi: 11.0-current rpi2 systat -vmstat shows around 24k interrupts for bcm283x_dw References: <0A781C7D-C5F5-4931-AE38-D2FEC0848DCA@dsl-only.net> <85B1DF09-7D67-4031-B1E9-E4754CDC690A@dsl-only.net> <61560100-FB03-4A14-A869-25B1EF818F48@dsl-only.net> Cc: freebsd-arm From: Karl Denninger Message-ID: <567FFE7D.40403@denninger.net> Date: Sun, 27 Dec 2015 09:06:37 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <61560100-FB03-4A14-A869-25B1EF818F48@dsl-only.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000003070004040305080403" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2015 15:06:48 -0000 This is a cryptographically signed message in MIME format. --------------ms000003070004040305080403 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/27/2015 02:33, Mark Millard wrote: > [I've moved the irq17 counts material into a tail section.] > > On 2015-Dec-26, at Sat Dec 26 23:07:43 UTC 2015 Karl Denninger wrote: > >> Hmmm... I wonder if this is related to the bcm sound driver going "mut= e" >> and needing a reboot to recover? > I've never plugged anything into the audio jack. The DVI monitor (via H= DMI->DVI cable) is soundless. (I've not wanted any sound from the rpi2 so= far and have done nothing to explicitly try to initiate such activity.) = The numbers are in the same range right after booting. I have several Pi2s running here doing various things and all show the same characteristic (very high) interrupt rate on that channel. Some are on hard-wired Ethernet and a couple on USB-WiFi dongles. None have keyboards, mice, or displays connected. > The dmesg -a output shows more information about irq17: > >> bcm283x_dwcotg0: mem= 0x980000-0x99ffff irq 17 on simplebus0 > > Booting with just the keyboard on usb (no Ethernet cable, no mouse, etc= =2E) still shows the same range of figures. Then unplugging the keyboard = while systat -vmstat is still displayed does not change the range either.= Yep. The rate does not appear to depend on what I have connected (or don't) to the various ports here. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms000003070004040305080403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMjcxNTA2MzdaME8GCSqGSIb3DQEJBDFCBEAp pw9py7Y+ktkbXPto8Cd8+PfEbS6AsVaog4tUHS1zWZLwMKX2S7JAVxW06N6GCRS+ne/N4X6k GYPE51iTjC9IMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAFJ+UXdP+ g4xl00cv0hXu5xx8VQb4AgEEWx4pMR5+AJi3W0DAGYAwf3HhktCRiJ94Jd+L6NgElO+MXSC2 VMoUP51tJ36QkNwTjwVWhwtjgnmm4h+vsKJhjLvtGZzeQ0IXUqeVIAH6Zl4wzrdG52nx9rsd qPLD250w1D7Cdro5ko0wXZElBoSTKCXsa8M3W+CHgXOeGDHOm2xgm0B5imZElBZBUbPyISdq cB0m3zC5qPe57pp3A/nxrdJZbAhUesNBN0t7RWiWN2b0YQ1bcckkg4EqLGtCetyxbUyppW+p 1yrbF3G4eAgSaNfclZZOIBOAdHn8VP3HRWitkTtBxfkLbmggnsrZSBPhMft0MHiMEMZJzAHC vp3GHjfUbKqLthNFztHU4B+Q0zkCqcSYcBS/jCBKGIpecqWQCGNM9ZIjMgpoJPfnSCkC2XrQ RC/Uh8wp2d1Ne1SVpGKjYxf05Qd2d0M2oSdbzi2YgWYvoSxNpDrxVfzzwf9+X20p0NS90Hyn COl3AQYW5RlRwSBqdEj5WjSUbWhDXJNucw87IWNIhlGczECV7qyy7KSIGHhFmfh49Go5RY+G EirxgYA+mEbxPRtLPKADSJ/VqhFKvQBM2L2dAJmQbYeJuJPr5Uppv8hSweqj8mS63p/KHfKZ y1S1HoHKJPG34o6TRg+UCn4ltwYAAAAAAAA= --------------ms000003070004040305080403-- From owner-freebsd-arm@freebsd.org Sun Dec 27 17:31:19 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0EE8A5348F for ; Sun, 27 Dec 2015 17:31:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C1BD81346 for ; Sun, 27 Dec 2015 17:31:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBRHVJI8094638 for ; Sun, 27 Dec 2015 17:31:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196407] kernel modules fail on arm after r276047 Date: Sun, 27 Dec 2015 17:31:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2015 17:31:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D196407 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|Closed |Open --- Comment #3 from Ian Lepore --- Re-open. This problem is not fixed. There was a temporary workaround adde= d to kernel and module compiles, but there is currently no proper solution and no workaround in place for userland compiles with -march=3Darmv7 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sun Dec 27 18:57:59 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60BF3A52D90 for ; Sun, 27 Dec 2015 18:57:59 +0000 (UTC) (envelope-from juan.rosero@oksigeno.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFF001FBC for ; Sun, 27 Dec 2015 18:57:58 +0000 (UTC) (envelope-from juan.rosero@oksigeno.com) Received: by mail-lf0-x236.google.com with SMTP id y184so189485789lfc.1 for ; Sun, 27 Dec 2015 10:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oksigeno.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=Cq6DWZv9GUfvuRfvQLWFzU4SPlJDEFvQpTb3x6apUs8=; b=pjPGp9YZVTUb8tL6pC1Vz0+RqxDBXlIYwtOh81/eTbqVF9cD+QmCCWJfzydjRS3vGx g8Rqjr5KLd9b1ZPl5R9yd7CaD6oE/jeuEbmzsE8g5BtjFggnhtvC8rEwU2FnwppFUq1q J98TZKaS07GnX0bQps3GMyzuT6THBOAG5vXwg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Cq6DWZv9GUfvuRfvQLWFzU4SPlJDEFvQpTb3x6apUs8=; b=GAR3xlFB0CvxuFUqrO4dlSQba0YC8lUD4l8UONWBIotq+QIG9+IyD1CDbs8M+z6g0c tA+7fTgiEJER0wY8UIzDMFbtulzZzFtZDbuIWR0W9ZX/ei3IORzQbu+tQIJbiOWh/ndE SiIo9VVFZXOctecPnOdzvVu8OpYQDMivhh9IfRGAfDkXhubKMBn2/Ochcza57FGNiNQl 1lVtq6vCEZUXbuXykv2hW9cnhphlmyjX12Z7sijavkfcTQqUJ7x0zkqKTflJm6c3Afc0 k0H8MQK3gEDv9EhsGswpqSpczXzEzwJ2hbx52+JXb3CSPB4GZbg1mIQbMbz4IF8UZrej OOYQ== X-Gm-Message-State: ALoCoQm+bWk+qFE6/tayqP2P6dkCBEEtccbELftpCWeG4KeFpBrli2xlmbJF/0MCt/dZlrYDnXmLOVPZu9PSfkrIJrdZWgPGIg== MIME-Version: 1.0 X-Received: by 10.25.83.193 with SMTP id h184mr17384968lfb.155.1451242675635; Sun, 27 Dec 2015 10:57:55 -0800 (PST) Received: by 10.112.96.134 with HTTP; Sun, 27 Dec 2015 10:57:55 -0800 (PST) X-Originating-IP: [190.131.152.231] Date: Sun, 27 Dec 2015 13:57:55 -0500 Message-ID: Subject: BeagleBoard-X15 From: =?UTF-8?Q?Modus_Latinoam=C3=A9rica_=2D_Juan_Manuel_Rosero_Puente?= To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2015 18:57:59 -0000 Does the BeagleBone Kernel File compilation compatible with the new BeagleBoard-X15 or somebody who already test it, please any comments are welcome! http://beagleboard.org/x15 From owner-freebsd-arm@freebsd.org Sun Dec 27 21:44:26 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 613A3A5233C for ; Sun, 27 Dec 2015 21:44:26 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 324581DB9 for ; Sun, 27 Dec 2015 21:44:25 +0000 (UTC) (envelope-from brett@lariat.net) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id QAA23506 for ; Thu, 24 Dec 2015 16:49:29 -0700 (MST) Message-Id: <201512242349.QAA23506@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 24 Dec 2015 16:49:18 -0700 To: freebsd-arm@freebsd.org From: Brett Glass Subject: Getting started with FreeBSD on CUBOX i2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2015 21:44:26 -0000 All: I'm interested in experimenting with FreeBSD on various small and embedded ARM boards during the coming year, and just acquired a CuBox-i2 to work with. I downloaded the file FreeBSD-11.0-CURRENT-arm-armv6-CUBOX-HUMMINGBOARD-20151217-r292413.img.xz from the FreeBSD FTP server, decompressed it, and wrote the image to an 8 GB micro SD card from a Windows machine. I then placed the card into the CuBox and tried to boot it. I was hopeful when the display showed a message from the U-Boot boot loader. But then a bunch of random pixels appeared and the screen went blank. Where am I going wrong? I'll probably dig into the technical details of development for this system shortly, but right now I'd just like to boot a prebuilt image and explore... and I'm not succeeding at doing this. Note that the CuBox *will* boot the manufacturer's "ignition" downloader, which in turn will download and flash quite a few versions of Linux. So, I know that the hardware is functional. However, their downloader doesn't offer a working image of FreeBSD as an option. --Brett Glass From owner-freebsd-arm@freebsd.org Sun Dec 27 21:45:33 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C6DAA523E8 for ; Sun, 27 Dec 2015 21:45:33 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 430C41E1E for ; Sun, 27 Dec 2015 21:45:33 +0000 (UTC) (envelope-from brett@lariat.net) Received: (from brett@localhost) by mail.lariat.net (8.9.3/8.9.3) id OAA28860 for freebsd-arm@freebsd.org; Sun, 27 Dec 2015 14:45:31 -0700 (MST) Date: Sun, 27 Dec 2015 14:45:31 -0700 (MST) From: Brett Glass Message-Id: <201512272145.OAA28860@mail.lariat.net> To: freebsd-arm@freebsd.org Subject: Getting started with freebsd-arm on Cubox-i2 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2015 21:45:33 -0000 All: I'm interested in experimenting with FreeBSD on various small and embedded ARM boards during the coming year, and just acquired a CuBox-i2 to work with. I downloaded the file FreeBSD-11.0-CURRENT-arm-armv6-CUBOX-HUMMINGBOARD-20151217-r292413.img.xz from the FreeBSD FTP server, decompressed it, and wrote the image to an 8 GB micro SD card from a Windows machine. I then placed the card into the CuBox and tried to boot it. I was hopeful when the display showed a message from the U-Boot boot loader. But then a bunch of random pixels appeared and the screen went blank. Where am I going wrong? I'll probably dig into the technical details of development for this system shortly, but right now I'd just like to boot a prebuilt image and explore... and I'm not succeeding at doing this. Note that the CuBox *will* boot the manufacturer's "ignition" downloader, which in turn will download and flash quite a few versions of Linux. So, I know that the hardware is functional. However, their downloader doesn't offer a working image of FreeBSD as an option. --Brett Glass From owner-freebsd-arm@freebsd.org Sun Dec 27 22:00:52 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5EBAA529EE for ; Sun, 27 Dec 2015 22:00:52 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 708C11A92 for ; Sun, 27 Dec 2015 22:00:51 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.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 6768D1FE024; Sun, 27 Dec 2015 23:00:42 +0100 (CET) Subject: Re: fyi: 11.0-current rpi2 systat -vmstat shows around 24k interrupts for bcm283x_dw To: Mark Millard , freebsd-arm References: <0A781C7D-C5F5-4931-AE38-D2FEC0848DCA@dsl-only.net> From: Hans Petter Selasky Message-ID: <56806007.2000302@selasky.org> Date: Sun, 27 Dec 2015 23:02:47 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <0A781C7D-C5F5-4931-AE38-D2FEC0848DCA@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2015 22:00:52 -0000 On 12/26/15 21:51, Mark Millard wrote: > Context: > >> # freebsd-version -ku; uname -aKU >> 11.0-CURRENT >> 11.0-CURRENT >> FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r292413M: Fri Dec 25 18:03:19 PST 2015 root@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm 1100091 1100091 > > > For a basically near-idle context systat -vmstat lists "Int" and 23k to 25k normally (almost always 24k) and bcm283x_dw at the right shows figures like 24118. "generic_ti" is more like 232 and "ipi 76" is more like 111. The others at the right are normally blank (other than total). > > Lots of bcm283x_dw interrupts if around 24k is correct. As the numbers do not change scale when the systat refresh interval is explicitly scaled, I assume that the figures are per second (or per some other time unit, possibly just for the most recent unit instead of mean). > > I'm not sure it will be readable but the below is a capture of a systat -vmstat display. > Hi, The dwc_otg needs to be served frequently in PIO mode. Your number is expected. We're using fast interrupts for most of this work, so no task-switching is involved and so the CPU consumption remains low. You can disable USB like this: usbconfig -d 0.1 set_config 255 And the interrupts should go down to zero. Re-enable like this: usbconfig -d 0.1 set_config 0 --HPS From owner-freebsd-arm@freebsd.org Sun Dec 27 23:04:23 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C6B3A52058 for ; Sun, 27 Dec 2015 23:04:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (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 86F3E1D24 for ; Sun, 27 Dec 2015 23:04:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28715 invoked from network); 27 Dec 2015 23:04:14 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 27 Dec 2015 23:04:14 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 27 Dec 2015 18:04:16 -0500 (EST) Received: (qmail 10778 invoked from network); 27 Dec 2015 23:04:16 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 27 Dec 2015 23:04:16 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id EA552B1E001; Sun, 27 Dec 2015 15:04:09 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: fyi: 11.0-current rpi2 systat -vmstat shows around 24k interrupts for bcm283x_dw From: Mark Millard In-Reply-To: <56806007.2000302@selasky.org> Date: Sun, 27 Dec 2015 15:04:13 -0800 Cc: freebsd-arm Message-Id: <2D9BD203-03D8-4354-A335-8C43A11D1BB3@dsl-only.net> References: <0A781C7D-C5F5-4931-AE38-D2FEC0848DCA@dsl-only.net> <56806007.2000302@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.2104) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2015 23:04:23 -0000 On 2015-Dec-27, at 2:02 PM, Hans Petter Selasky wrote: >=20 > On 12/26/15 21:51, Mark Millard wrote: >> Context: >>=20 >>> # freebsd-version -ku; uname -aKU >>> 11.0-CURRENT >>> 11.0-CURRENT >>> FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r292413M: Fri Dec = 25 18:03:19 PST 2015 = root@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm = 1100091 1100091 >>=20 >>=20 >> For a basically near-idle context systat -vmstat lists "Int" and 23k = to 25k normally (almost always 24k) and bcm283x_dw at the right shows = figures like 24118. "generic_ti" is more like 232 and "ipi 76" is more = like 111. The others at the right are normally blank (other than total). >>=20 >> Lots of bcm283x_dw interrupts if around 24k is correct. As the = numbers do not change scale when the systat refresh interval is = explicitly scaled, I assume that the figures are per second (or per some = other time unit, possibly just for the most recent unit instead of = mean). >>=20 >> I'm not sure it will be readable but the below is a capture of a = systat -vmstat display. >>=20 >=20 > Hi, >=20 > The dwc_otg needs to be served frequently in PIO mode. Your number is = expected. We're using fast interrupts for most of this work, so no = task-switching is involved and so the CPU consumption remains low. >=20 > You can disable USB like this: >=20 > usbconfig -d 0.1 set_config 255 >=20 > And the interrupts should go down to zero. >=20 > Re-enable like this: >=20 > usbconfig -d 0.1 set_config 0 >=20 > --HPS Good to know. Thanks. I'm unlikely to disable USB: I've not set up a = alternate serial connection. FYI (but probably unrelated?): I've not tracked anything down yet but I = do periodically get messages like: Dec 27 07:31:56 rpi2 kernel: bcm_dma0: unused DMA intr CH=3D3, = CS=3D20f10027 Dec 27 07:39:24 rpi2 kernel: bcm_dma0: unused DMA intr CH=3D3, = CS=3D20f10027 Dec 27 07:41:02 rpi2 kernel: bcm_dma0: unused DMA intr CH=3D3, = CS=3D20f10027 Dec 27 07:43:51 rpi2 kernel: bcm_dma0: unused DMA intr CH=3D3, = CS=3D20f10027 (But I also go long times without such.) Note: I'm currently involved in experiments providing evidence about Bus = Errors from software that misaligns pointer values and possibly from = inappropriate/insufficient compiler options for the SCTLR bit[1]=3D=3D1 = status. clang++ is one of the programs getting Bus Errors. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Dec 27 23:06:20 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4204A521F4 for ; Sun, 27 Dec 2015 23:06:20 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A1B8E10F0 for ; Sun, 27 Dec 2015 23:06:20 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 3969622977D for ; Sun, 27 Dec 2015 17:06:13 -0600 (CST) Subject: Re: fyi: 11.0-current rpi2 systat -vmstat shows around 24k interrupts for bcm283x_dw To: freebsd-arm@freebsd.org References: <0A781C7D-C5F5-4931-AE38-D2FEC0848DCA@dsl-only.net> <56806007.2000302@selasky.org> <2D9BD203-03D8-4354-A335-8C43A11D1BB3@dsl-only.net> From: Karl Denninger Message-ID: <56806EDE.9020806@denninger.net> Date: Sun, 27 Dec 2015 17:06:06 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <2D9BD203-03D8-4354-A335-8C43A11D1BB3@dsl-only.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030206070209090800010104" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2015 23:06:20 -0000 This is a cryptographically signed message in MIME format. --------------ms030206070209090800010104 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/27/2015 17:04, Mark Millard wrote: > > FYI (but probably unrelated?): I've not tracked anything down yet but I= do periodically get messages like: > > Dec 27 07:31:56 rpi2 kernel: bcm_dma0: unused DMA intr CH=3D3, CS=3D20f= 10027 > Dec 27 07:39:24 rpi2 kernel: bcm_dma0: unused DMA intr CH=3D3, CS=3D20f= 10027 > Dec 27 07:41:02 rpi2 kernel: bcm_dma0: unused DMA intr CH=3D3, CS=3D20f= 10027 > Dec 27 07:43:51 rpi2 kernel: bcm_dma0: unused DMA intr CH=3D3, CS=3D20f= 10027 > > (But I also go long times without such.) > > Note: I'm currently involved in experiments providing evidence about Bu= s Errors from software that misaligns pointer values and possibly from in= appropriate/insufficient compiler options for the SCTLR bit[1]=3D=3D1 sta= tus. clang++ is one of the programs getting Bus Errors. > > I get those all the time too, and I thought they were related to the audio going mute, but they're not related. There's a patch floating around that gets rid of those, but since it didn't take care of the audio problem and this doesn't appear to actually break anything I didn't leave it in when I last updated the tree. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms030206070209090800010104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMjcyMzA2MDZaME8GCSqGSIb3DQEJBDFCBEAR eMWqKMRUM54t/eDmdSVNa0d35Wq/EaCQ3aHnu/TY4xDTTsfqkXyZ1p6FJw8THwrDSuOqOVTG M3f3/eiVYqicMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIArrw8IPJu zyst/UB1gR14BRsl8eXwCOf4bYqgZ3Dy5lB0QLDAeh3LLpLYYPDHB/YSQ8exhaUs97G7eznJ PBUoo6h706LajwcdAzQDv7JGwFxe2HyseHLwNimTaMglsvR9UiJ0hY3x5gPhKZehl65D2lYX 7kTwJ64o6wEh7VbKhxys6B/FQhVAR5s5MLDhlyk0c60lxTnicN2bveR1TtjgWtJcOyEo7NsD ha4Vtft0LyGLDm8xeiZ6AH4IDoLGih5HkHqkZPGOPgskm5NSMQb85jPcyaA6eOQmHc7b/tr2 bts6NLmX1Ab/vYhAO9TB24VqViaQZ0PXGAQkgIlz90eHlx5EpNxlspPtNkkj5mWRcEMeuplF WWr1/8LbTsMIuFYsAaes3bSV1s6KlKOYpN439GFkFIWN46nYtzVI0X0mU7L1gGQwLXTMNR43 /2kiGujm9h3r2/9gnjR5D5B8yXmCBTSkpDmdvRzljWQWWBTFYlHUuZOyx9s7mK+2iNcnthcl 8B2xrJP/kEBP4cbRe99nC87fhk4Cc+S51t18Ai8z5IBYPVN9YiBcDdCarC64T55/md/fTubo hYun/PAzG4vg60HJ+YpCiteyM9C1i9mm0sFb3F9EPWvl5BCzL/ACN9+6n6eF/oodOiiK0nUM yCfREqRWo1hVJP7j+2SG4Deyc/IAAAAAAAA= --------------ms030206070209090800010104-- From owner-freebsd-arm@freebsd.org Mon Dec 28 00:54:09 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84AEFA51369 for ; Mon, 28 Dec 2015 00:54:09 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 694D11253 for ; Mon, 28 Dec 2015 00:54:08 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 28 Dec 2015 00:54:30 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBS0s6XV012871; Sun, 27 Dec 2015 17:54:06 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1451264046.1369.21.camel@freebsd.org> Subject: Re: Getting started with freebsd-arm on Cubox-i2 From: Ian Lepore To: Brett Glass , freebsd-arm@freebsd.org Date: Sun, 27 Dec 2015 17:54:06 -0700 In-Reply-To: <201512272145.OAA28860@mail.lariat.net> References: <201512272145.OAA28860@mail.lariat.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 00:54:09 -0000 On Sun, 2015-12-27 at 14:45 -0700, Brett Glass wrote: > All: > > I'm interested in experimenting with FreeBSD on various small and > embedded ARM boards during the coming year, and just acquired a CuBox > -i2 to work with. I downloaded the file > > FreeBSD-11.0-CURRENT-arm-armv6-CUBOX-HUMMINGBOARD-20151217 > -r292413.img.xz > > from the FreeBSD FTP server, decompressed it, and wrote the image to > an 8 GB micro SD card from a Windows machine. I then placed the card > into the CuBox and tried to boot it. > > I was hopeful when the display showed a message from the U-Boot boot > loader. But then a bunch of random pixels appeared and the screen > went blank. > > Where am I going wrong? I'll probably dig into the technical details > of development for this system shortly, but right now I'd just like > to boot a prebuilt image and explore... and I'm not succeeding at > doing this. > > Note that the CuBox *will* boot the manufacturer's "ignition" > downloader, which in turn will download and flash quite a few > versions of Linux. So, I know that the hardware is functional. > However, their downloader doesn't offer a working image of FreeBSD as > an option. > > --Brett Glass The video support for imx6 chips was just committed a few days ago and isn't in the image you downloaded. The cubox is likely booting just fine and sitting at a login prompt that you can't see. The cubox has a built in usb-serial adapter for the console. Just plug a micro-usb cable into the slot to the right of the sdcard and connect it to any computer with a terminal program (on freebsd use cu -l /dev/cuaU0 -s 115200). -- Ian From owner-freebsd-arm@freebsd.org Mon Dec 28 01:42:31 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CFF8A521F4 for ; Mon, 28 Dec 2015 01:42:31 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 572EF1198; Mon, 28 Dec 2015 01:42:31 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-pf0-x22c.google.com with SMTP id e65so52828440pfe.1; Sun, 27 Dec 2015 17:42:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:content-transfer-encoding:message-id:date :subject:from:in-reply-to:references:to; bh=XgOlF9ltNZD/tOaabWmD3TaTNpH4qU5sTbNnChaUGuI=; b=u5vvIRvYoXROKtoDl9sEGjijnprUp5ziFwpfW6+o/KFgT9aKz+bnD1BBhSCWrmjL9X nv3roXs4+ehwKLlABzlFMvAu50lmMbZETzbsaB9a1so+30pEGtvV02ilgaZqfepgCrac KcLRBK09vy2T+eXc9iLQAxnMaOTwzyLfyLxzSJjViopB7UDZkVVBfPYs/oSTXUO+F4Jr ZzIpeIp9XqSkXOFLoFLyQtVfqvlFwvTQJYsJ200iE52ZE5T/Z8dKxu+DiKehaQnh0ODr QUBBKxOsEmG2ozfoZ1uHYWAR14qwY9GnlQHet4CtLcJF+KQAhOGW0lijgebAD02cqS/s bnNg== X-Received: by 10.98.13.84 with SMTP id v81mr74094669pfi.120.1451266951037; Sun, 27 Dec 2015 17:42:31 -0800 (PST) Received: from [127.0.0.1] ([216.113.200.184]) by smtp.gmail.com with ESMTPSA id v11sm24561791pfa.81.2015.12.27.17.42.29 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Dec 2015 17:42:30 -0800 (PST) Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20151228014229.4374611.85214.1795@gmail.com> Date: Sun, 27 Dec 2015 17:42:29 -0800 Subject: Re: Getting started with freebsd-arm on Cubox-i2 From: Russell Haley In-Reply-To: <1451264046.1369.21.camel@freebsd.org> References: <201512272145.OAA28860@mail.lariat.net> <1451264046.1369.21.camel@freebsd.org> To: Ian Lepore , Brett Glass , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 01:42:31 -0000 I had the same output from my hummingboard when I had the wrong dtb file bu= t I never confirmed the HDMI worked (my PC is down so I can't check). The i= 2 is the dual-lite SOM and the image has the dtb file for the dual/quad var= iant. It could be he's hitting a kernel panic due to mis-configuration? Just a thought. Russ Sent=A0from=A0my=A0BlackBerry=A010=A0smartphone=A0on=A0the=A0Koodo=A0networ= k. =A0 Original Message =A0 From: Ian Lepore Sent: Sunday, December 27, 2015 4:54 PM To: Brett Glass; freebsd-arm@freebsd.org Subject: Re: Getting started with freebsd-arm on Cubox-i2 On Sun, 2015-12-27 at 14:45 -0700, Brett Glass wrote: > All: >=20 > I'm interested in experimenting with FreeBSD on various small and > embedded ARM boards during the coming year, and just acquired a CuBox > -i2 to work with. I downloaded the file >=20 > FreeBSD-11.0-CURRENT-arm-armv6-CUBOX-HUMMINGBOARD-20151217 > -r292413.img.xz >=20 > from the FreeBSD FTP server, decompressed it, and wrote the image to > an 8 GB micro SD card from a Windows machine. I then placed the card > into the CuBox and tried to boot it. >=20 > I was hopeful when the display showed a message from the U-Boot boot > loader. But then a bunch of random pixels appeared and the screen > went blank. >=20 > Where am I going wrong? I'll probably dig into the technical details > of development for this system shortly, but right now I'd just like > to boot a prebuilt image and explore... and I'm not succeeding at > doing this. >=20 > Note that the CuBox *will* boot the manufacturer's "ignition" > downloader, which in turn will download and flash quite a few > versions of Linux. So, I know that the hardware is functional. > However, their downloader doesn't offer a working image of FreeBSD as > an option. >=20 > --Brett Glass The video support for imx6 chips was just committed a few days ago and isn't in the image you downloaded. The cubox is likely booting just fine and sitting at a login prompt that you can't see. The cubox has a built in usb-serial adapter for the console. Just plug a micro-usb cable into the slot to the right of the sdcard and connect it to any computer with a terminal program (on freebsd use cu -l /dev/cuaU0 -s 115200). -- Ian _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Mon Dec 28 02:30:48 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B96AA4C538 for ; Mon, 28 Dec 2015 02:30:48 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 4495C1B2A; Mon, 28 Dec 2015 02:30:48 +0000 (UTC) (envelope-from brett@lariat.net) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id TAA01501; Sun, 27 Dec 2015 19:30:43 -0700 (MST) Message-Id: <201512280230.TAA01501@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 27 Dec 2015 19:30:17 -0700 To: Ian Lepore , freebsd-arm@freebsd.org From: Brett Glass Subject: Re: Getting started with freebsd-arm on Cubox-i2 In-Reply-To: <1451264046.1369.21.camel@freebsd.org> References: <201512272145.OAA28860@mail.lariat.net> <1451264046.1369.21.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 02:30:48 -0000 Ian: Thank you! Interestingly, when I plugged in a USB cable from a Windows computer, it recognized the USB serial port (which means that the USB-serial chip was getting power) but did not seem to be powering the CuBox. But when I connected a separate 5V power supply, I got a bootstrap and was able to log in as root with PuTTY, using the password "root". About half of the applications I will have for these boards will not require video support, and so I may want to do builds that are serial-only. On the CuBox-i2 which I have here, top(8) reports Mem: 11M Active, 10M Inact, 19M Wired, 4081K Buf, 956M Free which accounts for only 1000M of the 1024M -- suggesting that the remaining 24M are reserved for video. Or are they? On this chipset, is it possible to recover the video buffer RAM for general use in a "headless" system? --Brett Glass At 05:54 PM 12/27/2015, Ian Lepore wrote: >The video support for imx6 chips was just committed a few days ago and >isn't in the image you downloaded. The cubox is likely booting just >fine and sitting at a login prompt that you can't see. > >The cubox has a built in usb-serial adapter for the console. Just plug >a micro-usb cable into the slot to the right of the sdcard and connect >it to any computer with a terminal program (on freebsd use cu -l >/dev/cuaU0 -s 115200). > >-- Ian From owner-freebsd-arm@freebsd.org Mon Dec 28 03:10:19 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23FEBA4D316 for ; Mon, 28 Dec 2015 03:10:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 086CE145B for ; Mon, 28 Dec 2015 03:10:18 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 28 Dec 2015 03:10:41 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBS3AGme013085; Sun, 27 Dec 2015 20:10:16 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1451272216.1369.25.camel@freebsd.org> Subject: Re: Getting started with freebsd-arm on Cubox-i2 From: Ian Lepore To: Brett Glass , freebsd-arm@freebsd.org Date: Sun, 27 Dec 2015 20:10:16 -0700 In-Reply-To: <201512280230.TAA01501@mail.lariat.net> References: <201512272145.OAA28860@mail.lariat.net> <1451264046.1369.21.camel@freebsd.org> <201512280230.TAA01501@mail.lariat.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 03:10:19 -0000 On Sun, 2015-12-27 at 19:30 -0700, Brett Glass wrote: > Ian: > > Thank you! Interestingly, when I plugged in a USB cable from a > Windows computer, it recognized the USB serial port (which means > that the USB-serial chip was getting power) but did not seem to be > powering the CuBox. But when I connected a separate 5V power > supply, I got a bootstrap and was able to log in as root with > PuTTY, using the password "root". > > About half of the applications I will have for these boards will > not require video support, and so I may want to do builds that are > serial-only. On the CuBox-i2 which I have here, top(8) reports > > Mem: 11M Active, 10M Inact, 19M Wired, 4081K Buf, 956M Free > > which accounts for only 1000M of the 1024M -- suggesting that the > remaining 24M are reserved for video. Or are they? On this chipset, > is it possible to recover the video buffer RAM for general use in a > "headless" system? Yeah, you can't power it via the usb, the system needs more power than that, especially when graphics is enabled. Since there are no video drivers in the image you're running, there's no memory wasted on a framebuffer. The remaining memory is the kernel itself and page tables and other things that aren't accounted for by the vm system, which is where the numbers in top come from. -- Ian From owner-freebsd-arm@freebsd.org Mon Dec 28 10:16:52 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C171A53072 for ; Mon, 28 Dec 2015 10:16:52 +0000 (UTC) (envelope-from mazhe@alkumuna.eu) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 243E51D60 for ; Mon, 28 Dec 2015 10:16:51 +0000 (UTC) (envelope-from mazhe@alkumuna.eu) Received: from yggdrasil.alkumuna.eu (unknown [IPv6:2a01:e35:8a74:6e70:232:36ff:fe5c:3a87]) by smtp1-g21.free.fr (Postfix) with ESMTPS id A7AC2940219 for ; Mon, 28 Dec 2015 11:16:14 +0100 (CET) Received: from [192.168.11.10] (ADijon-656-1-22-237.w90-13.abo.wanadoo.fr [90.13.37.237]) (authenticated bits=0) by yggdrasil.alkumuna.eu (8.15.2/8.15.2) with ESMTPSA id tBSAGYAX047878 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Dec 2015 11:16:41 +0100 (CET) (envelope-from mazhe@alkumuna.eu) From: Matthieu Volat X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_7F4C00A1-C114-487F-88E3-A538816EB211"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Mon, 28 Dec 2015 11:16:29 +0100 Subject: Raspberry Pi and WaveShare SpotPear LCD screens To: freebsd-arm@freebsd.org Message-Id: <36285EFC-0739-4A93-B22D-C22B7BDEE16D@alkumuna.eu> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 10:16:52 -0000 --Apple-Mail=_7F4C00A1-C114-487F-88E3-A538816EB211 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi everybody, I brought a WaveShare SpotPear LCD screen for my Raspberry Pi B+ board, = having seen on the wiki page that LCD screen were working. But this kind of screen uses the GPIO connectors rather than the = dedicated display bus. It seems that even with Raspbian, it needs a = special image to work. The question is: does anybody have experience with those screens, would = it simply require DFT modifications or something more? I cannot find = sources on the supplement CD provided in the package. Thanks, -- Matthieu Volat --Apple-Mail=_7F4C00A1-C114-487F-88E3-A538816EB211 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlaBDAEACgkQ+ENDeYKZi36drQCfVm9qWf8dWdyHbYTa2MKwmPJj wEoAoK37FfpsMql3sMUFuwyM7m6v8GGt =6CTd -----END PGP SIGNATURE----- --Apple-Mail=_7F4C00A1-C114-487F-88E3-A538816EB211-- From owner-freebsd-arm@freebsd.org Mon Dec 28 11:33:13 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46A0BA545EA for ; Mon, 28 Dec 2015 11:33:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (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 F15C419CF for ; Mon, 28 Dec 2015 11:33:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18667 invoked from network); 28 Dec 2015 11:33:10 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Dec 2015 11:33:10 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 28 Dec 2015 06:33:09 -0500 (EST) Received: (qmail 27301 invoked from network); 28 Dec 2015 11:33:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 Dec 2015 11:33:09 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E784D1C43A0; Mon, 28 Dec 2015 03:33:08 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error? From: Mark Millard In-Reply-To: <118D2970-4799-46B1-81A1-0101B907C1BE@dsl-only.net> Date: Mon, 28 Dec 2015 03:33:09 -0800 Cc: freebsd-arm , FreeBSD Toolchain , Ian Lepore , mat@FreeBSD.org, sbruno@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <9DA7895D-B3DE-41FD-900C-EC95BDE19728@dsl-only.net> References: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@dsl-only.net> <0D81C2CA-BF1C-4C14-B816-A8C5F68715B5@bsdimp.com> <51EB4AAB-BC81-4282-BA4D-D329C41D660B@dsl-only.net> <8B52074F-FDEF-4119-BB04-630F9BE9E6DB@bsdimp.com> <118D2970-4799-46B1-81A1-0101B907C1BE@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 11:33:13 -0000 [I have both dropped a bunch of older history and started a new break.] The clang++ Bus Errors are a compiler implementation defect(!), as shown = below. (Presumes they want clang++ to work in contexts where alignment = is required.) In summary: The clang++ source code presumes that there are no alignment criteria to = be met for TemplateArgument instances from the "arg buffer" for any = DependentTemplateSpecializationType instance. The details. . . I finally have a 11-line example source file (no includes) that crashes = clang++ on the rpi2. (The example is a partial item from libc++'s = .) > # more main.cc > template > struct __has_rebind > { > template static char __test(typename _Xp::template = rebind<_Up>* =3D 0); > }; >=20 > int > main () > { > return 0; > } The backtrace in clang++ looks like: > Program terminated with signal 10, Bus error. > #0 0x00c404d0 in = clang::DependentTemplateSpecializationType::DependentTemplateSpecializatio= nType () > [New Thread 22a18000 (LWP 100182/)] > (gdb) bt > #0 0x00c404d0 in = clang::DependentTemplateSpecializationType::DependentTemplateSpecializatio= nType () > #1 0x00d86634 in = clang::ASTContext::getDependentTemplateSpecializationType () > #2 0x00d865d8 in = clang::ASTContext::getDependentTemplateSpecializationType () > #3 0x00d862d4 in = clang::ASTContext::getDependentTemplateSpecializationType () > #4 0x00553b7c in clang::Sema::ActOnTypenameType () > #5 0x0040cb68 in clang::Parser::TryAnnotateTypeOrScopeToken () > #6 0x00471198 in $a.28 () > #7 0x00471198 in $a.28 () > (gdb) x/1i 0x00c404d0 > 0xc404d0 = <_ZN5clang35DependentTemplateSpecializationTypeC2ENS_21ElaboratedTypeKeywo= rdEPNS_19NestedNameSpecifierEPKNS_14IdentifierInfoEjPKNS_16TemplateArgumen= tENS_8QualTypeE+356>:=09 > vst1.64 {d16-d17}, [r4]! > (gdb) info all-registers > r0 0xbfbf9778 -1077962888 > r1 0x22ac59c4 581720516 > r2 0xc45ff8 12869624 > r3 0x2 2 > r4 0x22ac59ac 581720492 . . . The code involved is from lib/AST/Type.cpp : > = DependentTemplateSpecializationType::DependentTemplateSpecializationType( > ElaboratedTypeKeyword Keyword, > NestedNameSpecifier *NNS, const = IdentifierInfo *Name, > unsigned NumArgs, const TemplateArgument = *Args, > QualType Canon) > : TypeWithKeyword(Keyword, DependentTemplateSpecialization, Canon, = true, true, > /*VariablyModified=3D*/false, > NNS && NNS->containsUnexpandedParameterPack()), > NNS(NNS), Name(Name), NumArgs(NumArgs) { > assert((!NNS || NNS->isDependent()) && > "DependentTemplateSpecializatonType requires dependent = qualifier"); > for (unsigned I =3D 0; I !=3D NumArgs; ++I) { > if (Args[I].containsUnexpandedParameterPack()) > setContainsUnexpandedParameterPack(); > =20 > new (&getArgBuffer()[I]) TemplateArgument(Args[I]); > } > } The failing code is for the "placement new" in the loop: A) &getArgBuffer()[I] is not always an address for which the vst1.64 = instruction gets an aligned address. but. . . B) TemplateArgument(Args[I])'s copy construction activity has code (such = as the vst1.64) requiring a specific alignment when SCTLR bit[1]=3D=3D1. C) Nothing here has any explicitly packed data structures. As for (A): > class DependentTemplateSpecializationType : > public TypeWithKeyword, public llvm::FoldingSetNode { > . . . > const TemplateArgument *getArgBuffer() const { > return reinterpret_cast(this+1); > } > TemplateArgument *getArgBuffer() { > return reinterpret_cast(this+1); > } clang++ is over-allocating the space for the = DependentTemplateSpecializationType objects and using the extra space = that is afterwards to hold (a somewhat C-style array of) = TemplateArgument instances. But the logic for this does nothing explicit = about alignment of the TemplateArgument instance pointers, not even = partially via explicitly controlling = sizeof(DependentTemplateSpecializationType). This code does not explicitly force any specific minimum = TemplateArgument alignment, other than 1. Separately there is the issue that the code produced did not treat the = pointers returned from getArgBuffer() methods as "opaque pointer" = examples but they are. Having compiled with -fmax-type-align=3D4 the = code should have not have required 8 byte alignment (vst1.64). It should = have produced code that required 4 (or 2 or 1). Quoting for = -fmax-type-align=3D?: > Instruct the code generator to not enforce a higher alignment than the = given number (of bytes) when accessing memory via an opaque pointer or = reference Those pointers certainly are opaque and should be treated as such. The = "reinterpret_cast" use is a big clue that clang++ should respect. In other words: I see two clang++ defects in the overall evidence, one = of which directly leads to the Bus Errors being possible. The script of the buildworld/buildkernel shows that -fmax-type-align=3D4 = -mno-unaligned-access were both used to compile the Type.cpp source = file: > --- Type.o --- > /usr/bin/clang++ -target armv6--freebsd11.0-gnueabi -march=3Darmv7a = -fmax-type-align=3D4 -mno-unaligned-access -target = armv6-gnueabi-freebsd11.0 --sysroot=3D/usr/obj/clang/arm.armv6/usr/src/tmp= -B/usr/local > /arm-gnueabi-freebsd/bin/ = --sysroot=3D/usr/obj/clang/arm.armv6/usr/src/tmp = -B/usr/local/arm-gnueabi-freebsd/bin/ -O -pipe -mfloat-abi=3Dsoftfp = -I/usr/src/lib/clang/libclangast/../../../contrib/llvm/inclu > de = -I/usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include= = -I/usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST= -I. -I/usr/src/lib/clang/libclangast/../../../c > ontrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD = -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT = -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFA > ULT_TARGET_TRIPLE=3D\"armv6-gnueabi-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"armv6-unknown-freebsd11.0\" = -DDEFAULT_SYSROOT=3D\"\" -MD -MP -MF.depend.Type.o -MTType.o = -Qunused-arguments -std=3Dc++11 -fno-exceptio > ns -fno-rtti -stdlib=3Dlibc++ -Wno-c++11-extensions -c = /usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/T= ype.cpp -o Type.o clang++ may well have other examples of such things in other classes. I = have not looked. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Dec-28, at 12:01 AM, Mark Millard wrote: >=20 >=20 > On 2015-Dec-26, at 8:45 AM, Warner Losh wrote: >=20 >> Thanks, it sounds like I fixed a bug, but there=E2=80=99s more. >>=20 >> What were the specific port so I can test it here? >>=20 >> And to be clear, this is a buildworld on the RPi 2 using the = cross-built world with CPUTYPE=3Darmv7a or some such, right? >>=20 >> Warner >>=20 >>> On Dec 25, 2015, at 9:32 PM, Mark Millard = wrote: >>>=20 >>> [I am again breaking off another section of older material.] >>>=20 >>> Mixed news I'm afraid. >>>=20 >>> The specific couple of ports that I attempted did build, the same = ones that originally got the Bus Error in ar using (indirectly) _fseeko = and memset that I reported. So I expect that you fixed one error. >>>=20 >>> But when I tried to buildworld, clang++ 3.7 processing = usr/src/lib/clang/libllvmtablegen/ materials quickly got a Bus Error at = nearly the same type of instruction (it has a "!" below that the earlier = one did not), but with r4 holding the misaligned address this time: >>>=20 >>>> --- _bootstrap-tools-lib/clang/libllvmsupport --- >>>> --- APFloat.o --- >>>> clang++: error: unable to execute command: Bus error (core dumped) >>>> . . . >>>> # gdb clang++ usr/src/lib/clang/libllvmtablegen/clang++.core >>>> . . . >>>> Core was generated by `clang++'. >>>> Program terminated with signal 10, Bus error. >>>> #0 0x00c3bb9c in = clang::DependentTemplateSpecializationType::DependentTemplateSpecializatio= nType () >>>> [New Thread 22a18000 (LWP 100128/)] >>>> (gdb) x/40i 0x00c3bb60 >>>> . . . >>>> 0xc3bb9c = <_ZN5clang35DependentTemplateSpecializationTypeC2ENS_21ElaboratedTypeKeywo= rdEPNS_19NestedNameSpecifierEPKNS_14IdentifierInfoEjPKNS_16TemplateArgumen= tENS_8QualTypeE+356>: >>>> vst1.64 {d16-d17}, [r4]! >>>> . . . >>>> (gdb) info all-registers >>>> r0 0xbfbf81a8 -1077968472 >>>> r1 0x22f07e14 586186260 >>>> r2 0xc416bc 12850876 >>>> r3 0x2 2 >>>> r4 0x22f07dfc 586186236 >>>> . . . >>>=20 >>>=20 >>> Thus it appears that there is more code around that likely generates = pointers not aligned so to allow the code generation that is in use for = what is pointed to. >>>=20 >>> At this point I have no clue if the issue is just inside clang = itself vs. if it is in something that clang is layered on top of. Nor if = there is just one bad thing or many. >>>=20 >>> Note: I had not yet tried buildworld/buildkernel for the context of = the "-f" option that I was experimenting with earlier. So I do not have = a direct compare and contrast at this point. >=20 > Somehow I did not notice your E-mail at the time. Meanwhile I've more = evidence. . . >=20 > [Initial context for notes: Before updating to 11.0-CURRENT -r292756 = and its clang/clang++ 3.7.1.] >=20 > Example c++ program that clang++ got an internal Bus Error for: >=20 >> # more main.cc >> #include >> int >> main () >> { >> std::ostream *o; return 0; >> } >=20 > Of course the include makes the source being processed non-trivial. >=20 > Going in a different direction. . . dmesg -a | grep "core dumped" on = the rpi2 showed: >=20 >> pid 22238 (msgfmt), uid 0: exited on signal 11 (core dumped) >> pid 22250 (xgettext), uid 0: exited on signal 11 (core dumped) >> pid 22259 (msgmerge), uid 0: exited on signal 11 (core dumped) >> pid 26149 (msgfmt), uid 0: exited on signal 11 (core dumped) >> pid 26161 (xgettext), uid 0: exited on signal 11 (core dumped) >> pid 26170 (msgmerge), uid 0: exited on signal 11 (core dumped) >> pid 28826 (c++), uid 0: exited on signal 10 (core dumped) >> pid 29202 (c++), uid 0: exited on signal 10 (core dumped) >> pid 29282 (c++), uid 0: exited on signal 10 (core dumped) >> pid 29292 (clang++), uid 0: exited on signal 10 (core dumped) >=20 > Only the c++/clang++ contexts (same but for name) seemed to be leaving = .core files behind. >=20 > The older log files also showed examples like the following from ports = building activity: >=20 >> /var/log/dmesg.today:pid 18763 (conftest), uid 0: exited on signal 11 = (core dumped) >> /var/log/dmesg.today:pid 18916 (conftest), uid 0: exited on signal 11 = (core dumped) >=20 > (The original ar that I started with showed as well, the records went = back that far at the time.) >=20 > [New -r292756 context. . .] >=20 > After the above I updated to: >=20 >> $ freebsd-version -ku; uname -aKU >> 11.0-CURRENT >> 11.0-CURRENT >> FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r292756M: Sun Dec = 27 02:55:57 PST 2015 = root@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm = 1100092 1100092 >=20 > in order to pick up clang 3.7.1. I used -fmax-type-align=3D4 = -mno-unaligned-access in the src.conf file for the buildworld = buildkernel amd64->rpi2 cross build before installing both parts on the = rpi2 media. >=20 > On the rpi2 itself the resulting c++/clang++ still gets Bus Error = during buildworld despite the use of -fmax-type-align=3D4 = -mno-unaligned-acces in the amd64 hosted cross build (and in the rpi2 = attempted rebuild). An example crash report is: >=20 >> /usr/bin/clang++ -B/usr/local/arm-gnueabi-freebsd/bin -march=3Darmv7a = -fmax-type-align=3D4 -mno-unaligned-access -O -pipe -mfloat-abi=3Dsoftfp = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/incl= ude = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support = -I. = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/= include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv6-gnueabi-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"armv6-unknown-freebsd11.0\" = -DDEFAULT_SYSROOT=3D\"\" -MD -MP -MF.depend.APFloat.o -MTAPFloat.o = -Qunused-arguments = -I/usr/obj/clang/arm.armv6/usr/src/tmp/legacy/usr/include -std=3Dc++11 = -fno-exceptions -fno-rtti -stdlib=3Dlibc++ -Wno-c++11-extensions -c = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloa= t.cpp -o APFloat.o >> clang++: error: unable to execute command: Bus error (core dumped) >> clang++: error: clang frontend command failed due to signal (use -v = to see invocation) >> FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 >> Target: armv6--freebsd11.0-gnueabi >> Thread model: posix >> clang++: note: diagnostic msg: PLEASE submit a bug report to = https://bugs.freebsd.org/submit/ and include the crash backtrace, = preprocessed source, and associated run script. >> clang++: note: diagnostic msg:=20 >> ******************** >>=20 >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> Preprocessed source(s) and associated run script(s) are located at: >> clang++: note: diagnostic msg: /tmp/APFloat-04544c.cpp >> clang++: note: diagnostic msg: /tmp/APFloat-04544c.sh >> clang++: note: diagnostic msg:=20 >>=20 >> ******************** >> *** Error code 254 >>=20 >> Stop. >> make[3]: stopped in /usr/src/lib/clang/libllvmsupport >> *** Error code 1 >=20 > An earlier -j 6 buildworld had failures for ARMBuildAttrs, APSInt, = APInt, and Error before stopping, in addition to the APFloat indicated = above (no -j makes for easier reading above): >=20 >> # ls -lt /tmp >> total 41516 >> -rw-r--r-- 1 root wheel 4057 Dec 28 03:05 APFloat-04544c.sh >> -rw-r--r-- 1 root wheel 2155452 Dec 28 03:05 APFloat-04544c.cpp >> -rw-r--r-- 1 root wheel 4081 Dec 28 02:53 = ARMBuildAttrs-432569.sh >> -rw-r--r-- 1 root wheel 1276912 Dec 28 02:53 = ARMBuildAttrs-432569.cpp >> -rw-r--r-- 1 root wheel 3997 Dec 28 02:53 APSInt-a2927e.sh >> -rw-r--r-- 1 root wheel 1943445 Dec 28 02:53 APSInt-a2927e.cpp >> -rw-r--r-- 1 root wheel 3985 Dec 28 02:53 APInt-d0389a.sh >> -rw-r--r-- 1 root wheel 2115595 Dec 28 02:53 APInt-d0389a.cpp >> -rw-r--r-- 1 root wheel 4009 Dec 28 02:53 APFloat-33be1b.sh >> -rw-r--r-- 1 root wheel 2155452 Dec 28 02:53 APFloat-33be1b.cpp >> -rw-r--r-- 1 root wheel 4001 Dec 28 02:53 Error-777068.sh >> -rw-r--r-- 1 root wheel 1925065 Dec 28 02:53 Error-777068.cpp >=20 > The earlier "iostream" program example also still gets its Bus Error = during its clang++ based compilation in this new -r292756 context. >=20 > The above -r292756 material avoids involving ports software with its = own set of additional questions, compilers, tools, etc.: it sticks to = buildworld/buildkernel material (and never gets to buildkernel). >=20 > When I tried -j 5 buildkernel by itself on the rpi2 there were no Bus = Errors, no Segmentation Faults, and no core dumps. The buildkernel took = about 51 minutes. (I've not tried installing what it built.) >=20 > (I have a SSD on a USB hub in use for world/root on the rpi2. The = /etc/fstab on the micro-SD lists / as mounting from the SSD instead. I = installkernel and installworld via the amd64 context to both the = micro-SD and the SSD so that they track. I can boot from just the = micro-SD if I want to but normally involve the SSD.) >=20 > Another kind of experiment would be to omit -fmax-type-align=3D4 but = use -mno-unaligned-access (for handling any packed data structures) and = see if buildkernel can still finish on the rpi2 (if enough of the = amd64->rpi2 buildworld still operates on the rpi2 to allow the test). >=20 > A potential experiment for buildworld would be to use = -fmax-type-align=3D1 with -mno-unaligned-access as the amd64->rpi2 cross = build context. A misalignment Bus Error from that context might well be = a clang++ code generation error of not paying attention to the alignment = rules where clang++ should. >=20 > A potentially interesting (but independent) set of warnings during the = buildkernel was: >=20 >> WARNING: hwpmc_mod.c: enum pmc_event has too many values: 2588 > 1023 >> WARNING: hwpmc_logging.c: enum pmc_event has too many values: 2588 > = 1023 >> WARNING: hwpmc_soft.c: enum pmc_event has too many values: 2588 > = 1023 >> WARNING: hwpmc_arm.c: enum pmc_event has too many values: 2588 > 1023 >=20 > (I've not investigated.) >=20 >=20 >=20 > Before this -r292756 update the following ports seemed to have built = without generating core dumps or Bus Error reports or other such in the = process: >=20 > devel/gettext-tools > devel/gmake-lite > devel/p5-Locale-gettext > lang/perl5.22 > security/sudo >=20 > Note that I did not use make.conf to force -f. . . and -m. . . for = these. But the test was if they could build, not if they operated = correctly when built. >=20 > My guess is that they are primarily C instead of C++ and/or happen to = avoid the parts of C++ where clang++ is having internal data structure = alignment problems vs. SCTLR bit[1]=3D=3D1. >=20 > Generally the pkg installs on the rpi2 seemed to have been operating = okay. But they do nto test compiling/linking with the system = clang/clang++ involved. >=20 > In general building ports can have other issues that block completion = so I had not tried much in that direction and happened to pick on a few = things that worked (see above). Getting through a self-hosting rpi2 = buildworld buildkernel first likely is a better path before involving = ports. >=20 > But my way of working has involved using devel/arm-gnueabi-binutils , = which seemed to build and work fine. >=20 >=20 > One thing of note from all my rpi2 builds: I've learned to avoid doing = a "svnlite status /usr/src/" and similar commands. Fairly frequently = they do not complete and each existing ssh connection to the rpi2 quits = responding once some new program is attempted from the connection. The = same for directly at the rpi2 (via USB devices). >=20 > Unfortunately /var/log/messages only shows the following boot, no = messages from the hang-up context. I'd guess that USB (and other such?) = communication stopped operating. >=20 >=20 >=20 > The src.conf for on the rpi2 has (the amd64->rpi2 cross compile was = very similar but the amd64-host-targets-self clang/clang++ commands do = not need the -f. . . and -m. . . ): >=20 >> TO_TYPE=3Darmv6 >> TOOLS_TO_TYPE=3Darm-gnueabi >> FROM_TYPE=3D${TO_TYPE} >> TOOLS_FROM_TYPE=3D${TOOLS_TO_TYPE} >> VERSION_CONTEXT=3D11.0 >> # >> KERNCONF=3DRPI2-NODBG >> TARGET=3Darm >> .if ${.MAKE.LEVEL} =3D=3D 0 >> TARGET_ARCH=3D${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> WITHOUT_CROSS_COMPILER=3D >> # >> # For WITH_BOOT=3D . . . (amd64 cross compile context) >> # arm-gnueabi-freebsd/bin/ld reports bootinfo.o: relocation = R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a = shared object; recompile with -fPIC=20 >> WITHOUT_BOOT=3D >> # >> WITH_FAST_DEPEND=3D >> WITH_LIBCPLUSPLUS=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_LLDB=3D >> WITH_CLANG_EXTRAS=3D >> # >> WITHOUT_LIB32=3D >> WITHOUT_GCC=3D >> WITHOUT_GNUCXX=3D >> # >> NO_WERROR=3D >> MALLOC_PRODUCTION=3D >> #CFLAGS+=3D -DELF_VERBOSE >> # >> WITH_DEBUG=3D >> WITH_DEBUG_FILES=3D >> # >> # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related = bintutils... >> # >> #CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc >> X_COMPILER_TYPE=3Dclang >> CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ >> .if ${.MAKE.LEVEL} =3D=3D 0 >> XCC=3D/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> XCXX=3D/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> XCPP=3D/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> .export XCC >> .export XCXX >> .export XCPP >> XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as >> XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar >> XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld >> XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm >> XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy >> XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump >> XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib >> XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size >> #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings >> XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings >> .export XAS >> .export XAR >> .export XLD >> .export XNM >> .export XOBJCOPY >> .export XOBJDUMP >> .export XRANLIB >> .export XSIZE >> .export XSTRINGS >> .endif >> # >> # =46rom clang (via system)... >> # >> .if ${.MAKE.LEVEL} =3D=3D 0 >> CC=3D/usr/bin/clang -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> CXX=3D/usr/bin/clang++ -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> CPP=3D/usr/bin/clang-cpp -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> .export CC >> .export CXX >> .export CPP >> .endif >> # >> # >> # TOOLS_FROM_TYPE binutils from xtoolchain like context... >> # >> .if ${.MAKE.LEVEL} =3D=3D 0 >> AS=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/as >> AR=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ar >> LD=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ld >> NM=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/nm >> OBJCOPY=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/objcopy >> OBJDUMP=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/objdump >> RANLIB=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ranlib >> SIZE=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/size >> #NO-SUCH: STRINGS=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/strings >> STRINGS=3D/usr/local/bin/${TOOLS_FROM_TYPE}-freebsd-strings >> .export AS >> .export AR >> .export LD >> .export NM >> .export OBJCOPY >> .export OBJDUMP >> .export RANLIB >> .export SIZE >> .export STRINGS >> .endif >=20 > This technique does require devel/arm-gnueabi-binutils to have been = built and operating okay on amd64 and later on the rpi2. So far I've no = hints of any problems in that area. >=20 >=20 >=20 > The RPI2-NODBG config is shown below: >=20 >> # more /usr/src/sys/arm/conf/RPI2-NODBG=20 >> ident RPI2-NODBG >>=20 >> include "RPI2" >>=20 >> makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >> options ALT_BREAK_TO_DEBUGGER >> #options VERBOSE_SYSINIT # Enable verbose sysinit = messages >>=20 >> options KDB # Enable kernel debugger = support >>=20 >> # For minimum debugger support (stable branch) use: >> #options KDB_TRACE # Print a stack trace for a = panic >> options DDB # Enable the kernel debugger >>=20 >> nooptions INVARIANTS # Enable calls of extra = sanity checking >> nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS >> nooptions WITNESS # Enable checks to detect = deadlocks and cycles >> nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed >> nooptions DIAGNOSTIC >=20 >=20 > Most of my /usr/src/ tailoring is tied to powerpc and powerpc64 = issues: >=20 >> # svnlite status /usr/src/ >> ? /usr/src/.snap >> M /usr/src/contrib/libcxxrt/guard.cc >> M /usr/src/lib/csu/powerpc64/Makefile >> M /usr/src/lib/libc/stdio/findfp.c >> ? /usr/src/lib/libc/stdio/findfp.c.orig >> ? /usr/src/restoresymtable >> ? /usr/src/sys/arm/conf/RPI2-NODBG >> M /usr/src/sys/boot/ofw/Makefile.inc >> M /usr/src/sys/boot/powerpc/Makefile.inc >> M /usr/src/sys/boot/uboot/Makefile.inc >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG >> ? /usr/src/sys/powerpc/conf/GENERICvtsc >> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG >> M /usr/src/sys/powerpc/ofw/ofw_machdep.c >=20 > lib/libc/stdio/findfp.c has the patch I was asked to test. >=20 > contrib/libcxxrt/guard.cc is to avoid bad C++ source code (use of = C11-specific notation in C++ that is reported syntax errors in = powerpc64-xtoolchain-gcc/powerpc64-gcc compilation contexts): >=20 >> # svnlite diff /usr/src/contrib/libcxxrt/guard.cc >> Index: /usr/src/contrib/libcxxrt/guard.cc >> =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 >> --- /usr/src/contrib/libcxxrt/guard.cc (revision 292756) >> +++ /usr/src/contrib/libcxxrt/guard.cc (working copy) >> @@ -101,7 +101,7 @@ >> uint32_t init_half; >> uint32_t lock_half; >> } guard_t; >> -_Static_assert(sizeof(guard_t) =3D=3D sizeof(uint64_t), ""); >> +//_Static_assert(sizeof(guard_t) =3D=3D sizeof(uint64_t), ""); >> static const uint32_t LOCKED =3D 1; >> static const uint32_t INITIALISED =3D static_cast(1) << = 24; >> # endif >=20 > The sys/boot/. . . examples are just use of -Wl, notation in LDFLAGS = where the original notation was rejected, such as: >=20 >> # svnlite diff /usr/src/sys/boot/uboot/Makefile.inc >> Index: /usr/src/sys/boot/uboot/Makefile.inc >> =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 >> --- /usr/src/sys/boot/uboot/Makefile.inc (revision 292756) >> +++ /usr/src/sys/boot/uboot/Makefile.inc (working copy) >> @@ -2,7 +2,7 @@ >>=20 >> .if ${MACHINE_ARCH} =3D=3D "powerpc64" >> CFLAGS+=3D -m32 -mcpu=3Dpowerpc >> -LDFLAGS+=3D -m elf32ppc_fbsd >> +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd >> .endif >>=20 >> .include "../Makefile.inc" >=20 > All 3 are powerpc64 specific changes. >=20 > =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Dec 28 08:01:06 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96888A54D02 for ; Mon, 28 Dec 2015 08:01:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (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 4897D12A6 for ; Mon, 28 Dec 2015 08:01:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7411 invoked from network); 28 Dec 2015 08:01:03 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Dec 2015 08:01:03 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 28 Dec 2015 03:01:02 -0500 (EST) Received: (qmail 18125 invoked from network); 28 Dec 2015 08:01:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 Dec 2015 08:01:01 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C376F1C43A0; Mon, 28 Dec 2015 00:01:02 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error? From: Mark Millard In-Reply-To: Date: Mon, 28 Dec 2015 00:01:02 -0800 Cc: freebsd-arm , FreeBSD Toolchain , Ian Lepore , mat@FreeBSD.org, sbruno@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <118D2970-4799-46B1-81A1-0101B907C1BE@dsl-only.net> References: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@dsl-only.net> <0D81C2CA-BF1C-4C14-B816-A8C5F68715B5@bsdimp.com> <51EB4AAB-BC81-4282-BA4D-D329C41D660B@dsl-only.net> <8B52074F-FDEF-4119-BB04-630F9BE9E6DB@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.2104) X-Mailman-Approved-At: Mon, 28 Dec 2015 12:13:37 +0000 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 08:01:06 -0000 On 2015-Dec-26, at 8:45 AM, Warner Losh wrote: > Thanks, it sounds like I fixed a bug, but there=E2=80=99s more. >=20 > What were the specific port so I can test it here? >=20 > And to be clear, this is a buildworld on the RPi 2 using the = cross-built world with CPUTYPE=3Darmv7a or some such, right? >=20 > Warner >=20 >> On Dec 25, 2015, at 9:32 PM, Mark Millard = wrote: >>=20 >> [I am again breaking off another section of older material.] >>=20 >> Mixed news I'm afraid. >>=20 >> The specific couple of ports that I attempted did build, the same = ones that originally got the Bus Error in ar using (indirectly) _fseeko = and memset that I reported. So I expect that you fixed one error. >>=20 >> But when I tried to buildworld, clang++ 3.7 processing = usr/src/lib/clang/libllvmtablegen/ materials quickly got a Bus Error at = nearly the same type of instruction (it has a "!" below that the earlier = one did not), but with r4 holding the misaligned address this time: >>=20 >>> --- _bootstrap-tools-lib/clang/libllvmsupport --- >>> --- APFloat.o --- >>> clang++: error: unable to execute command: Bus error (core dumped) >>> . . . >>> # gdb clang++ usr/src/lib/clang/libllvmtablegen/clang++.core >>> . . . >>> Core was generated by `clang++'. >>> Program terminated with signal 10, Bus error. >>> #0 0x00c3bb9c in = clang::DependentTemplateSpecializationType::DependentTemplateSpecializatio= nType () >>> [New Thread 22a18000 (LWP 100128/)] >>> (gdb) x/40i 0x00c3bb60 >>> . . . >>> 0xc3bb9c = <_ZN5clang35DependentTemplateSpecializationTypeC2ENS_21ElaboratedTypeKeywo= rdEPNS_19NestedNameSpecifierEPKNS_14IdentifierInfoEjPKNS_16TemplateArgumen= tENS_8QualTypeE+356>: >>> vst1.64 {d16-d17}, [r4]! >>> . . . >>> (gdb) info all-registers >>> r0 0xbfbf81a8 -1077968472 >>> r1 0x22f07e14 586186260 >>> r2 0xc416bc 12850876 >>> r3 0x2 2 >>> r4 0x22f07dfc 586186236 >>> . . . >>=20 >>=20 >> Thus it appears that there is more code around that likely generates = pointers not aligned so to allow the code generation that is in use for = what is pointed to. >>=20 >> At this point I have no clue if the issue is just inside clang itself = vs. if it is in something that clang is layered on top of. Nor if there = is just one bad thing or many. >>=20 >> Note: I had not yet tried buildworld/buildkernel for the context of = the "-f" option that I was experimenting with earlier. So I do not have = a direct compare and contrast at this point. Somehow I did not notice your E-mail at the time. Meanwhile I've more = evidence. . . [Initial context for notes: Before updating to 11.0-CURRENT -r292756 and = its clang/clang++ 3.7.1.] Example c++ program that clang++ got an internal Bus Error for: > # more main.cc > #include > int > main () > { > std::ostream *o; return 0; > } Of course the include makes the source being processed non-trivial. Going in a different direction. . . dmesg -a | grep "core dumped" on the = rpi2 showed: > pid 22238 (msgfmt), uid 0: exited on signal 11 (core dumped) > pid 22250 (xgettext), uid 0: exited on signal 11 (core dumped) > pid 22259 (msgmerge), uid 0: exited on signal 11 (core dumped) > pid 26149 (msgfmt), uid 0: exited on signal 11 (core dumped) > pid 26161 (xgettext), uid 0: exited on signal 11 (core dumped) > pid 26170 (msgmerge), uid 0: exited on signal 11 (core dumped) > pid 28826 (c++), uid 0: exited on signal 10 (core dumped) > pid 29202 (c++), uid 0: exited on signal 10 (core dumped) > pid 29282 (c++), uid 0: exited on signal 10 (core dumped) > pid 29292 (clang++), uid 0: exited on signal 10 (core dumped) Only the c++/clang++ contexts (same but for name) seemed to be leaving = .core files behind. The older log files also showed examples like the following from ports = building activity: > /var/log/dmesg.today:pid 18763 (conftest), uid 0: exited on signal 11 = (core dumped) > /var/log/dmesg.today:pid 18916 (conftest), uid 0: exited on signal 11 = (core dumped) (The original ar that I started with showed as well, the records went = back that far at the time.) [New -r292756 context. . .] After the above I updated to: > $ freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r292756M: Sun Dec 27 = 02:55:57 PST 2015 = root@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm = 1100092 1100092 in order to pick up clang 3.7.1. I used -fmax-type-align=3D4 = -mno-unaligned-access in the src.conf file for the buildworld = buildkernel amd64->rpi2 cross build before installing both parts on the = rpi2 media. On the rpi2 itself the resulting c++/clang++ still gets Bus Error during = buildworld despite the use of -fmax-type-align=3D4 -mno-unaligned-acces = in the amd64 hosted cross build (and in the rpi2 attempted rebuild). An = example crash report is: > /usr/bin/clang++ -B/usr/local/arm-gnueabi-freebsd/bin -march=3Darmv7a = -fmax-type-align=3D4 -mno-unaligned-access -O -pipe -mfloat-abi=3Dsoftfp = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/incl= ude = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support = -I. = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/= include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv6-gnueabi-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"armv6-unknown-freebsd11.0\" = -DDEFAULT_SYSROOT=3D\"\" -MD -MP -MF.depend.APFloat.o -MTAPFloat.o = -Qunused-arguments = -I/usr/obj/clang/arm.armv6/usr/src/tmp/legacy/usr/include -std=3Dc++11 = -fno-exceptions -fno-rtti -stdlib=3Dlibc++ -Wno-c++11-extensions -c = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloa= t.cpp -o APFloat.o > clang++: error: unable to execute command: Bus error (core dumped) > clang++: error: clang frontend command failed due to signal (use -v to = see invocation) > FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 > Target: armv6--freebsd11.0-gnueabi > Thread model: posix > clang++: note: diagnostic msg: PLEASE submit a bug report to = https://bugs.freebsd.org/submit/ and include the crash backtrace, = preprocessed source, and associated run script. > clang++: note: diagnostic msg:=20 > ******************** >=20 > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > clang++: note: diagnostic msg: /tmp/APFloat-04544c.cpp > clang++: note: diagnostic msg: /tmp/APFloat-04544c.sh > clang++: note: diagnostic msg:=20 >=20 > ******************** > *** Error code 254 >=20 > Stop. > make[3]: stopped in /usr/src/lib/clang/libllvmsupport > *** Error code 1 An earlier -j 6 buildworld had failures for ARMBuildAttrs, APSInt, = APInt, and Error before stopping, in addition to the APFloat indicated = above (no -j makes for easier reading above): > # ls -lt /tmp > total 41516 > -rw-r--r-- 1 root wheel 4057 Dec 28 03:05 APFloat-04544c.sh > -rw-r--r-- 1 root wheel 2155452 Dec 28 03:05 APFloat-04544c.cpp > -rw-r--r-- 1 root wheel 4081 Dec 28 02:53 = ARMBuildAttrs-432569.sh > -rw-r--r-- 1 root wheel 1276912 Dec 28 02:53 = ARMBuildAttrs-432569.cpp > -rw-r--r-- 1 root wheel 3997 Dec 28 02:53 APSInt-a2927e.sh > -rw-r--r-- 1 root wheel 1943445 Dec 28 02:53 APSInt-a2927e.cpp > -rw-r--r-- 1 root wheel 3985 Dec 28 02:53 APInt-d0389a.sh > -rw-r--r-- 1 root wheel 2115595 Dec 28 02:53 APInt-d0389a.cpp > -rw-r--r-- 1 root wheel 4009 Dec 28 02:53 APFloat-33be1b.sh > -rw-r--r-- 1 root wheel 2155452 Dec 28 02:53 APFloat-33be1b.cpp > -rw-r--r-- 1 root wheel 4001 Dec 28 02:53 Error-777068.sh > -rw-r--r-- 1 root wheel 1925065 Dec 28 02:53 Error-777068.cpp The earlier "iostream" program example also still gets its Bus Error = during its clang++ based compilation in this new -r292756 context. The above -r292756 material avoids involving ports software with its own = set of additional questions, compilers, tools, etc.: it sticks to = buildworld/buildkernel material (and never gets to buildkernel). When I tried -j 5 buildkernel by itself on the rpi2 there were no Bus = Errors, no Segmentation Faults, and no core dumps. The buildkernel took = about 51 minutes. (I've not tried installing what it built.) (I have a SSD on a USB hub in use for world/root on the rpi2. The = /etc/fstab on the micro-SD lists / as mounting from the SSD instead. I = installkernel and installworld via the amd64 context to both the = micro-SD and the SSD so that they track. I can boot from just the = micro-SD if I want to but normally involve the SSD.) Another kind of experiment would be to omit -fmax-type-align=3D4 but use = -mno-unaligned-access (for handling any packed data structures) and see = if buildkernel can still finish on the rpi2 (if enough of the = amd64->rpi2 buildworld still operates on the rpi2 to allow the test). A potential experiment for buildworld would be to use -fmax-type-align=3D1= with -mno-unaligned-access as the amd64->rpi2 cross build context. A = misalignment Bus Error from that context might well be a clang++ code = generation error of not paying attention to the alignment rules where = clang++ should. A potentially interesting (but independent) set of warnings during the = buildkernel was: > WARNING: hwpmc_mod.c: enum pmc_event has too many values: 2588 > 1023 > WARNING: hwpmc_logging.c: enum pmc_event has too many values: 2588 > = 1023 > WARNING: hwpmc_soft.c: enum pmc_event has too many values: 2588 > 1023 > WARNING: hwpmc_arm.c: enum pmc_event has too many values: 2588 > 1023 (I've not investigated.) Before this -r292756 update the following ports seemed to have built = without generating core dumps or Bus Error reports or other such in the = process: devel/gettext-tools devel/gmake-lite devel/p5-Locale-gettext lang/perl5.22 security/sudo Note that I did not use make.conf to force -f. . . and -m. . . for = these. But the test was if they could build, not if they operated = correctly when built. My guess is that they are primarily C instead of C++ and/or happen to = avoid the parts of C++ where clang++ is having internal data structure = alignment problems vs. SCTLR bit[1]=3D=3D1. Generally the pkg installs on the rpi2 seemed to have been operating = okay. But they do nto test compiling/linking with the system = clang/clang++ involved. In general building ports can have other issues that block completion so = I had not tried much in that direction and happened to pick on a few = things that worked (see above). Getting through a self-hosting rpi2 = buildworld buildkernel first likely is a better path before involving = ports. But my way of working has involved using devel/arm-gnueabi-binutils , = which seemed to build and work fine. One thing of note from all my rpi2 builds: I've learned to avoid doing a = "svnlite status /usr/src/" and similar commands. Fairly frequently they = do not complete and each existing ssh connection to the rpi2 quits = responding once some new program is attempted from the connection. The = same for directly at the rpi2 (via USB devices). Unfortunately /var/log/messages only shows the following boot, no = messages from the hang-up context. I'd guess that USB (and other such?) = communication stopped operating. The src.conf for on the rpi2 has (the amd64->rpi2 cross compile was very = similar but the amd64-host-targets-self clang/clang++ commands do not = need the -f. . . and -m. . . ): > TO_TYPE=3Darmv6 > TOOLS_TO_TYPE=3Darm-gnueabi > FROM_TYPE=3D${TO_TYPE} > TOOLS_FROM_TYPE=3D${TOOLS_TO_TYPE} > VERSION_CONTEXT=3D11.0 > # > KERNCONF=3DRPI2-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITHOUT_CROSS_COMPILER=3D > # > # For WITH_BOOT=3D . . . (amd64 cross compile context) > # arm-gnueabi-freebsd/bin/ld reports bootinfo.o: relocation = R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a = shared object; recompile with -fPIC=20 > WITHOUT_BOOT=3D > # > WITH_FAST_DEPEND=3D > WITH_LIBCPLUSPLUS=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_LLDB=3D > WITH_CLANG_EXTRAS=3D > # > WITHOUT_LIB32=3D > WITHOUT_GCC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > MALLOC_PRODUCTION=3D > #CFLAGS+=3D -DELF_VERBOSE > # > WITH_DEBUG=3D > WITH_DEBUG_FILES=3D > # > # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related = bintutils... > # > #CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc > X_COMPILER_TYPE=3Dclang > CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ > .if ${.MAKE.LEVEL} =3D=3D 0 > XCC=3D/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access > XCXX=3D/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access > XCPP=3D/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access > .export XCC > .export XCXX > .export XCPP > XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as > XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar > XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld > XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm > XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy > XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump > XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib > XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size > #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings > XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings > .export XAS > .export XAR > .export XLD > .export XNM > .export XOBJCOPY > .export XOBJDUMP > .export XRANLIB > .export XSIZE > .export XSTRINGS > .endif > # > # =46rom clang (via system)... > # > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3D/usr/bin/clang -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access > CXX=3D/usr/bin/clang++ -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access > CPP=3D/usr/bin/clang-cpp -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access > .export CC > .export CXX > .export CPP > .endif > # > # > # TOOLS_FROM_TYPE binutils from xtoolchain like context... > # > .if ${.MAKE.LEVEL} =3D=3D 0 > AS=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/as > AR=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ar > LD=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ld > NM=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/nm > OBJCOPY=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/objcopy > OBJDUMP=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/objdump > RANLIB=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ranlib > SIZE=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/size > #NO-SUCH: STRINGS=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/strings > STRINGS=3D/usr/local/bin/${TOOLS_FROM_TYPE}-freebsd-strings > .export AS > .export AR > .export LD > .export NM > .export OBJCOPY > .export OBJDUMP > .export RANLIB > .export SIZE > .export STRINGS > .endif This technique does require devel/arm-gnueabi-binutils to have been = built and operating okay on amd64 and later on the rpi2. So far I've no = hints of any problems in that area. The RPI2-NODBG config is shown below: > # more /usr/src/sys/arm/conf/RPI2-NODBG=20 > ident RPI2-NODBG >=20 > include "RPI2" >=20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols > options ALT_BREAK_TO_DEBUGGER > #options VERBOSE_SYSINIT # Enable verbose sysinit = messages >=20 > options KDB # Enable kernel debugger = support >=20 > # For minimum debugger support (stable branch) use: > #options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger >=20 > nooptions INVARIANTS # Enable calls of extra sanity = checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed > nooptions DIAGNOSTIC Most of my /usr/src/ tailoring is tied to powerpc and powerpc64 issues: > # svnlite status /usr/src/ > ? /usr/src/.snap > M /usr/src/contrib/libcxxrt/guard.cc > M /usr/src/lib/csu/powerpc64/Makefile > M /usr/src/lib/libc/stdio/findfp.c > ? /usr/src/lib/libc/stdio/findfp.c.orig > ? /usr/src/restoresymtable > ? /usr/src/sys/arm/conf/RPI2-NODBG > M /usr/src/sys/boot/ofw/Makefile.inc > M /usr/src/sys/boot/powerpc/Makefile.inc > M /usr/src/sys/boot/uboot/Makefile.inc > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/src/sys/powerpc/conf/GENERICvtsc > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/src/sys/powerpc/ofw/ofw_machdep.c lib/libc/stdio/findfp.c has the patch I was asked to test. contrib/libcxxrt/guard.cc is to avoid bad C++ source code (use of = C11-specific notation in C++ that is reported syntax errors in = powerpc64-xtoolchain-gcc/powerpc64-gcc compilation contexts): > # svnlite diff /usr/src/contrib/libcxxrt/guard.cc > Index: /usr/src/contrib/libcxxrt/guard.cc > =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 > --- /usr/src/contrib/libcxxrt/guard.cc (revision 292756) > +++ /usr/src/contrib/libcxxrt/guard.cc (working copy) > @@ -101,7 +101,7 @@ > uint32_t init_half; > uint32_t lock_half; > } guard_t; > -_Static_assert(sizeof(guard_t) =3D=3D sizeof(uint64_t), ""); > +//_Static_assert(sizeof(guard_t) =3D=3D sizeof(uint64_t), ""); > static const uint32_t LOCKED =3D 1; > static const uint32_t INITIALISED =3D static_cast(1) << = 24; > # endif The sys/boot/. . . examples are just use of -Wl, notation in LDFLAGS = where the original notation was rejected, such as: > # svnlite diff /usr/src/sys/boot/uboot/Makefile.inc > Index: /usr/src/sys/boot/uboot/Makefile.inc > =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 > --- /usr/src/sys/boot/uboot/Makefile.inc (revision 292756) > +++ /usr/src/sys/boot/uboot/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" All 3 are powerpc64 specific changes. =3D=3D=3D Mark Millard markmi at dsl-only.net >=20 > Older material: >=20 > On 2015-Dec-25, at 5:21 PM, Mark Millard wrote: >=20 >> On 2015-Dec-25, at 3:42 PM, Warner Losh wrote: >>=20 >>=20 >>> On Dec 25, 2015, at 3:14 PM, Mark Millard = wrote: >>>=20 >>> [I'm going to break much of the earlier "original material" text to = tail of the message.] >>>=20 >>>> On 2015-Dec-25, at 11:53 AM, Warner Losh wrote: >>>>=20 >>>> So what happens if we actually fix the underlying bug? >>>>=20 >>>> I see two ways of doing this. In findfp.c, we allocate an array of = FILE * today like: >>>> g =3D (struct glue *)malloc(sizeof(*g) + ALIGNBYTES + n * = sizeof(FILE)); >>>> but that assumes that FILE just has normal pointer alignment = requirements. However, >>>> due to the mbstate having int64_t alignment requirements, this is = wrong. Maybe we >>>> need to do something like >>>> g =3D (struct glue *)malloc(sizeof(*g) + = max(sizeof(int64_t),ALIGNBYTES) + n * sizeof(FILE)); >>>> which wouldn=E2=80=99t change anything on LP64 systems, but would = result in proper alignment >>>> for ILP32 systems. We=E2=80=99d have to fix the loop that uses = ALIGN afterwards to use >>>> roundup. Instead, we=E2=80=99d need to round up to the neared = 8-byte aligned offset (or technically, >>>> the max of ALIGNBYTES and 8, but that=E2=80=99s always 8 on = today=E2=80=99s systems. If we do this, >>>> we can make sure that each file is 8-byte aligned or better. We may = need to round up >>>> sizeof(FILE) to a multiple of 8 as well. I believe that since it = has the 8-byte alignment >>>> for a member, its size must be a multiple of 8, but I=E2=80=99ve = not chased that belief to ground. >>>> If not, we may need another decorator (__aligned(8), I think, = spelled with the ugly >>>> max expression above). That way, the contract we=E2=80=99re making = with the compiler will >>>> always be true. ALIGN BYTES is 4 on Arm anyway, so that bit is = clearly wrong. >>>>=20 >>>> This wouldn=E2=80=99t be an ABI change, since you can only get a = valid FILE * from fopen (and >>>> friends), plus stdin, stdout, and stderr. Those addresses aren=E2=80=99= t hard coded into binaries, >>>> so even if we have to tweak the last three and deal with some = =E2=80=98fake=E2=80=99 FILE abuse in libc >>>> (which I don=E2=80=99t think suffers from this issue, btw, given = the alignment requirements that would >>>> naturally follow from something on the stack), we=E2=80=99d still = be ahead. At least for all CONFORMING >>>> implementations[*]... >>>>=20 >>>> TL;DR: Why not make FILE * always 8-byte aligned? The compiler = options are a band-aide. >>>>=20 >>>> Warner >>>>=20 >>>> [*] There=E2=80=99s at least on popular package that has a copy of = the FILE structure in one of its >>>> .h files and uses that to do unnatural optimization things, but = even that=E2=80=99s cool, I think, >>>> since it never allocates a new one. >>>>=20 >>>=20 >>> The ARM documentation mentions cases of 16 byte alignment = requirements. I've no clue if the clang code generation ever creates = such code. There might be wider requirements possible in arm code as = well. (I'm not an arm expert.) As an example of an implication: "The = malloc() function returns a pointer to a block of at least size bytes = suitably aligned for any use." In other words: aligned to some figure = that is a multiple of *every* alignment requirement that the code = generator can produce, possibly being the least common multiple. >>>=20 >>> "-fmax-type-align=3D. . ." is a means of controlling/limiting the = range of potential alignments to no more than a fixed, predefined value. = Above that and the code generation has to work in small size accesses = and build-up/split-up bigger values. Using "-fmax-type-align=3D. . ." = allows defining a figure as part of an ABI that is then not subject to = code generator updates that could increase the maximum alignment figure = and break things: It turns off such new capabilities. Other options need = not work that way to preserve the ABI. >>=20 >> That=E2=80=99s true, as far as it goes=E2=80=A6 But I=E2=80=99m not = sure it goes far enough. The premise here is that the problem is = wide-spread, when in fact I think it is quite narrow. >>=20 >>> But in the most fundamental terms process wise as far as I can tell. = . . >>>=20 >>> While the FILE case that occurred is a specific example, every = memory-allocation-like operation is at a potential issue for all such = "allocated" objects where the related code generation requires alignment = to avoid Bus Error (given the SCTLR bit[1] in use). >>=20 >> The problem isn=E2=80=99t general. The problem isn=E2=80=99t malloc. = Malloc will generally return the right thing on arm (and if it = doesn=E2=80=99t, >> then we need to make sure it does). >>=20 >> The problem is we get a boatload of FILEs from the system all at = once, and those are misaligned because of a bug in the code. One = that=E2=80=99s fixed, I believe, in https://reviews.freebsd.org/D4708. >>=20 >>=20 >>> How many other places in FreeBSD might sometimes return mis-aligned = pointers for the existing code generation and ABI combination? >>=20 >> It isn=E2=80=99t an ABI thing, just a code bug thing. The only reason = it was an issue was due to the optimizing nature of clang. >>=20 >> We=E2=80=99ve had to deal with the arm alignment issues for years. I = wager there are very few indeed. The only reason this was was brought to = light was better code-gen from clang. >>=20 >>> How many other places are subject to breakage when "internal" = structs/unions/fields involved are changed to be of a different size = because the code is not fully auto-adjusting to match the code = generation yet --even if right now "it works"? How fragile will things = be for future work? >>=20 >> If there are others, I=E2=80=99ll bet they could be counted on one = hand since very few things do the =E2=80=98slab=E2=80=99 allocator that = FILE does. >>=20 >>> What would it take to find out and deal with them all? (I do not = have the background knowledge to span much.) >>>=20 >>> My experiment avoided potentially changing parts of the ABI and also = avoided dealing with such a "lots of code to investigate" issue. It may = not be the long term 11.0-RELEASE solution. Even if not, it may be = appropriate for various temporary purposes that need to avoid Bus Errors = in the process. For example if Ian has a good reason to use clang 3.7 = instead of gcc 4.2.1. >>=20 >> The review above doesn=E2=80=99t change the ABI either. >>=20 >>> Other notes: >>>=20 >>>> I believe that since it has the 8-byte alignment >>>> for a member, its size must be a multiple of 8 >>>=20 >>> There are some C/C++ language rules about the address of a structure = equalling the address of the first field, uniformity of the offsets, and = the like. But. . . >>>=20 >>> The C and C++ languages specify no specific numerical alignment = figures, not even relative to specific sizeof(...) expressions. To use = an old example: a 68010 only needs alignment for >=3D 2 byte things and = even alignment is all that is then required. Some other contexts take a = lot more to meet the specifications. There are some implications of the = modern memory model(s) created to cover concurrency explicitly, such as = avoiding interactions that can happen via, for example, separate objects = (in part) sharing a cache line. (I've only looked at C++ for this, and = only to a degree.) >>>=20 >>> The detailed alignment rules are more "implementation defined" than = "predefined by the standard". But the definition is trying to meet = language criteria. It is not a fully independent choice. >>=20 >> Many of them are actually defined by a combination of the standard = language definition, as well as the ABI standard. This is why we know = that mbstate_t must be 8 byte aligned. >>=20 >>> May be some other standards that FreeBSD is tied to specify more = specifics, such as a N byte integer always aligns to some multiple of N = (a waste on the 68010), including the alignment for union or struct that = it may be a part of tracking. But such rules force padding that may or = may not be required to meet the language's more abstract criteria and = such rules may not match the existing/in-use ABI. >>=20 >> It is all spelled out in the ARM EABI docs. >>=20 >>> So far as I can tell explicitly declared alignments may well be = necessary. If that one "popular package", say, formed an array of FILE = copies then the resultant alignments need not all match the ones = produced by your example code unless the FILE declaration forces the = compiler to match, causing sizeof(FILE) to track as well. FILE need not = be the only such issue. >>=20 >> Arrays of FILEs isn=E2=80=99t an issue (except that it encodes the = size of FILE into the app). It=E2=80=99s the specifically quirky way = that libc does it that=E2=80=99s the problem. >>=20 >>> My background and reference material are mostly tied the languages = --and so my notes tend to be limited to that much context. >>=20 >> Understood. While there may be issues with alignment still, tossing a = big hammer at the problem because they might exist will likely mean they = will persist far longer than fixing them one at a time. When we first = ported to arm, there were maybe half a dozen places that needed fixing. = I doubt there=E2=80=99s more now. >>=20 >> Can you try the patch in the above code review w/o the -f switch and = let me know if it works for you? >>=20 >> Warner >=20 > buildworld/buildkernel has been started on amd64 for a rpi2 target. = That and install kernel/world and starting up a port rebuild on the rpi2 = and waiting for it means it will be a few hours even if I start the next = thing just as each prior thing finishes. I may give up and go to sleep = first. >=20 > As for presumptions: I'll take your word on expected status of things. = I've no clue. But absent even the hear-say status information at the = time I did not presume that what was in front of me was all there is to = worry about --nor did I try to go figure it all out on my own. I took a = path to cover both possibilities for local-only vs. more-wide-spread (so = long as that path did not force a split-up of some larger form of atomic = action). >=20 > In my view "-mno-unaligned-access" is an even bigger hammer than I = used. I find no clang statement about what its ABI consequences would = be, unlike for what I did: What mix of more padding for alignment vs. = more but smaller accesses? But as I remember I've seen = "-mno-unaligned-access" in use in ports and the like so its consequences = may be familiar material for some folks. >=20 > Absent any questions about ABI consequences "-mno-unaligned-access" = does well mark the expected SCTLR bit[1] status, far better than what I = did. Again: I was covering my ignorance while making any significant = investigation/debugging as unlikely as I could. >=20 >=20 >> Original material: >>=20 >>> On Dec 25, 2015, at 7:24 AM, Mark Millard = wrote: >>>=20 >>> [Good News Summary: Rebuilding buildworld/buildkernel for rpi2 = 11.0-CURRENT 292413 from amd64 based on adding -fmax-type-align=3D4 has = so far removed the crashes during the toolchain activity: no more = misaligned accesses in libc's _fseeko or elsewhere.] >>>=20 >>> On 2015-Dec-25, at 12:31 AM, Mark Millard = wrote: >>>=20 >>>> On 2015-Dec-24, at 10:39 PM, Mark Millard = wrote: >>>>=20 >>>>> [I do not know if this partial crash analysis related to on-arm = clang-associated activity is good enough and appropriate to submit or = not.] >>>>>=20 >>>>> The /usr/local/arm-gnueabi-freebsd/bin/ar on the rpi2b involved = below came from pkg install activity instead of port building. Used = as-is. >>>>>=20 >>>>> When I just tried my first from-rpi2b builds (ports for a rpi2b), = /usr/local/arm-gnueabi-freebsd/bin/ar crashed. I believe that the = following suggests an alignment error for the type of instructions that = memset for 128 bytes was translated to (sizeof(mbstate_t)) in the code = used by /usr/local/arm-gnueabi-freebsd/bin/ar. (But I do not know how to = check SCTLR bit[1] to be directly sure that alignment was being = enforced.) >>>>>=20 >>>>> The crash was a Bus error in /usr/local/arm-gnueabi-freebsd/bin/ar = : >>>>>=20 >>>>>> libtool: link: /usr/local/arm-gnueabi-freebsd/bin/ar cru = .libs/libgnuintl.a bindtextdom.o dcgettext.o dgettext.o gettext.o = finddomain.o hash-string.o loadmsgcat.o localealias.o textdomain.o = l10nflist.o explodename.o dcigettext.o dcngettext.o dngettext.o = ngettext.o pluralx.o plural-exp.o localcharset.o threadlib.o lock.o = relocatable.o langprefs.o localename.o log.o printf.o setlocale.o = version.o xsize.o osdep.o intl-compat.o >>>>>> Bus error (core dumped) >>>>>> *** [libgnuintl.la] Error code 138 >>>>>=20 >>>>> It failed in _fseeko doing a memset that turned into uses of = "vst1.64 {d16-d17}, [r0]" instructions, for an address in = register r0 that ended in 0xa4, so was not aligned to 8 byte boundaries. = =46rom what I read such "VSTn (multiple n-element structures)" that have = .64 require 8 byte alignment. The evidence of the code and register = value follow. >>>>>=20 >>>>>> # gdb /usr/local/arm-gnueabi-freebsd/bin/ar = /usr/obj/portswork/usr/ports/devel/gettext-tools/work/gettext-0.19.6/gette= xt-tools/intl/ar.core >>>>>> . . . >>>>>> #0 0x2033adcc in _fseeko (fp=3D0x20651dcc, offset=3D, whence=3D, ltest=3D) at /usr/src/lib/libc/stdio/fseek.c:299 >>>>>> 299 memset(&fp->_mbstate, 0, sizeof(mbstate_t)); >>>>>> . . . >>>>>> (gdb) x/24i 0x2033adb0 >>>>>> 0x2033adb0 <_fseeko+836>: vmov.i32 q8, #0 ; = 0x00000000 >>>>>> 0x2033adb4 <_fseeko+840>: movw r1, #65503 ; 0xffdf >>>>>> 0x2033adb8 <_fseeko+844>: stm r4, {r0, r7} >>>>>> 0x2033adbc <_fseeko+848>: ldrh r0, [r4, #12] >>>>>> 0x2033adc0 <_fseeko+852>: and r0, r0, r1 >>>>>> 0x2033adc4 <_fseeko+856>: strh r0, [r4, #12] >>>>>> 0x2033adc8 <_fseeko+860>: add r0, r4, #216 ; 0xd8 >>>>>> 0x2033adcc <_fseeko+864>: vst1.64 {d16-d17}, [r0] >>>>>> 0x2033add0 <_fseeko+868>: add r0, r4, #200 ; 0xc8 >>>>>> 0x2033add4 <_fseeko+872>: vst1.64 {d16-d17}, [r0] >>>>>> 0x2033add8 <_fseeko+876>: add r0, r4, #184 ; 0xb8 >>>>>> 0x2033addc <_fseeko+880>: vst1.64 {d16-d17}, [r0] >>>>>> 0x2033ade0 <_fseeko+884>: add r0, r4, #168 ; 0xa8 >>>>>> 0x2033ade4 <_fseeko+888>: vst1.64 {d16-d17}, [r0] >>>>>> 0x2033ade8 <_fseeko+892>: add r0, r4, #152 ; 0x98 >>>>>> 0x2033adec <_fseeko+896>: vst1.64 {d16-d17}, [r0] >>>>>> 0x2033adf0 <_fseeko+900>: add r0, r4, #136 ; 0x88 >>>>>> 0x2033adf4 <_fseeko+904>: vst1.64 {d16-d17}, [r0] >>>>>> 0x2033adf8 <_fseeko+908>: add r0, r4, #120 ; 0x78 >>>>>> 0x2033adfc <_fseeko+912>: vst1.64 {d16-d17}, [r0] >>>>>> 0x2033ae00 <_fseeko+916>: add r0, r4, #104 ; 0x68 >>>>>> 0x2033ae04 <_fseeko+920>: vst1.64 {d16-d17}, [r0] >>>>>> 0x2033ae08 <_fseeko+924>: b 0x2033b070 = <_fseeko+1540> >>>>>> 0x2033ae0c <_fseeko+928>: cmp r5, #0 ; 0x0 >>>>>> (gdb) info all-registers >>>>>> r0 0x20651ea4 543497892 >>>>>> r1 0xffdf 65503 >>>>>> r2 0x0 0 >>>>>> r3 0x0 0 >>>>>> r4 0x20651dcc 543497676 >>>>>> r5 0x0 0 >>>>>> r6 0x0 0 >>>>>> r7 0x0 0 >>>>>> r8 0x20359df4 540384756 >>>>>> r9 0x0 0 >>>>>> r10 0x0 0 >>>>>> r11 0xbfbfb948 -1077954232 >>>>>> r12 0x2037b208 540520968 >>>>>> sp 0xbfbfb898 -1077954408 >>>>>> lr 0x2035a004 540385284 >>>>>> pc 0x2033adcc 540257740 >>>>>> f0 0 (raw 0x000000000000000000000000) >>>>>> f1 0 (raw 0x000000000000000000000000) >>>>>> f2 0 (raw 0x000000000000000000000000) >>>>>> f3 0 (raw 0x000000000000000000000000) >>>>>> f4 0 (raw 0x000000000000000000000000) >>>>>> f5 0 (raw 0x000000000000000000000000) >>>>>> f6 0 (raw 0x000000000000000000000000) >>>>>> f7 0 (raw 0x000000000000000000000000) >>>>>> fps 0x0 0 >>>>>> cpsr 0x60000010 1610612752 >>>>>=20 >>>>> The syntax in use for vst1.64 instructions does not explicitly = have the alignment notation. Presuming that the decoding is correct then = from what I read the following applies: >>>>>=20 >>>>>> Home > NEON and VFP Programming > NEON load and store element and = structure instructions > Alignment restrictions in load and store, = element and structure instructions >>>>>>=20 >>>>>> . . . When the alignment is not specified in the instruction, the = alignment restriction is controlled by the A bit (SCTLR bit[1]): >>>>>> =E2=80=A2 if the A bit is 0, there are no alignment = restrictions (except for strongly ordered or device memory, where = accesses must be element aligned or the result is unpredictable) >>>>>> =E2=80=A2 if the A bit is 1, accesses must be element = aligned. >>>>>> If an address is not correctly aligned, an alignment fault = occurs. >>>>>=20 >>>>> So if at the time the "A bit" (SCTLR bit[1]) is 1 then the Bus = error would have the context to happen because of the mis-alignment. >>>>>=20 >>>>> The following shows the make.conf context that explains how = /usr/local/arm-gnueabi-freebsd/bin/ar came to be invoked: >>>>>=20 >>>>>> # more /etc/make.conf >>>>>> WRKDIRPREFIX=3D/usr/obj/portswork >>>>>> WITH_DEBUG=3D >>>>>> WITH_DEBUG_FILES=3D >>>>>> MALLOC_PRODUCTION=3D >>>>>> # >>>>>> TO_TYPE=3Darmv6 >>>>>> TOOLS_TO_TYPE=3Darm-gnueabi >>>>>> CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ >>>>>> .if ${.MAKE.LEVEL} =3D=3D 0 >>>>>> CC=3D/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a >>>>>> CXX=3D/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a >>>>>> CPP=3D/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a >>>>>> .export CC >>>>>> .export CXX >>>>>> .export CPP >>>>>> AS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as >>>>>> AR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar >>>>>> LD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld >>>>>> NM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm >>>>>> OBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy >>>>>> OBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump >>>>>> RANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib >>>>>> SIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size >>>>>> #NO-SUCH: STRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings= >>>>>> STRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings >>>>>> .export AS >>>>>> .export AR >>>>>> .export LD >>>>>> .export NM >>>>>> .export OBJCOPY >>>>>> .export OBJDUMP >>>>>> .export RANLIB >>>>>> .export SIZE >>>>>> .export STRINGS >>>>>> .endif >>>>>=20 >>>>>=20 >>>>> Other context: >>>>>=20 >>>>>> # freebsd-version -ku; uname -aKU >>>>>> 11.0-CURRENT >>>>>> 11.0-CURRENT >>>>>> FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r292413M: Tue = Dec 22 22:02:21 PST 2015 = root@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm = 1100091 1100091 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I will note that world and kernel are my own build of -r292413 = (earlier experiment) --a build made from an amd64 host context and put = in place via DESTDIR=3D. My expectation would be that the amd64 context = would not be likely to have similar alignment restrictions involved in = its ar activity (or other activity). That would explain how I got this = far using such a clang 3.7 related toolchain for targeting an rpi2 = before finding such a problem. >>>>=20 >>>>=20 >>>> I realized re-reading the all above that it seems to suggest that = the _fseeko code involved is from /usr/local/arm-gnueabi-freebsd/bin/ar = but that was not my intent. >>>>=20 >>>> libc.so.7 is from my buildworld, including the fseeko = implementation: >>>>=20 >>>> Reading symbols from /lib/libc.so.7...Reading symbols from = /usr/lib/debug//lib/libc.so.7.debug...done. >>>> done. >>>> Loaded symbols for /lib/libc.so.7 >>>>=20 >>>>=20 >>>> head/sys/sys/_types.h has: >>>>=20 >>>> /* >>>> * mbstate_t is an opaque object to keep conversion state during = multibyte >>>> * stream conversions. >>>> */ >>>> typedef union { >>>> char __mbstate8[128]; >>>> __int64_t _mbstateL; /* for alignment */ >>>> } __mbstate_t; >>>>=20 >>>> suggesting an implicit alignment of the union to whatever the = implementation defines for __int64_t --which need not be 8 byte = alignment (in the abstract, general case). But 8 byte alignment is a = possibility as well (in the abstract). >>>>=20 >>>> But printing *fp in gdb for the fp argument to _fseeko reports the = same not-8-byte aligned address for __mbstate8 that was in r0: >>>>=20 >>>>> (gdb) bt >>>>> #0 0x2033adcc in _fseeko (fp=3D0x20651dcc, offset=3D, whence=3D, ltest=3D) at /usr/src/lib/libc/stdio/fseek.c:299 >>>>> #1 0x2033b108 in fseeko (fp=3D0x20651dcc, offset=3D18571438587904, = whence=3D0) at /usr/src/lib/libc/stdio/fseek.c:82 >>>>> #2 0x00016138 in ?? () >>>>> (gdb) print fp >>>>> $2 =3D (FILE *) 0x20651dcc >>>>> (gdb) print *fp >>>>> $3 =3D {_p =3D 0x2069a240 "", _r =3D 0, _w =3D 0, _flags =3D 5264, = _file =3D 36, _bf =3D {_base =3D 0x2069a240 "", _size =3D 32768}, = _lbfsize =3D 0, _cookie =3D 0x20651dcc, _close =3D 0x20359dfc = <__sclose>, >>>>> _read =3D 0x20359de4 <__sread>, _seek =3D 0x20359df4 <__sseek>, = _write =3D 0x20359dec <__swrite>, _ub =3D {_base =3D 0x0, _size =3D 0}, = _up =3D 0x0, _ur =3D 0, _ubuf =3D 0x20651e0c "", _nbuf =3D 0x20651e0f = "", _lb =3D { >>>>> _base =3D 0x0, _size =3D 0}, _blksize =3D 32768, _offset =3D 0, = _fl_mutex =3D 0x0, _fl_owner =3D 0x0, _fl_count =3D 0, _orientation =3D = 0, _mbstate =3D {__mbstate8 =3D 0x20651e34 "", _mbstateL =3D 0}, _flags2 = =3D 0} >>>>=20 >>>> The overall FILE struct containing the _mbstate field is also not = 8-byte aligned. But the offset from the start of the FILE struct to = __mbstate8 is a multiple of 8 bytes. >>>>=20 >>>> It is my interpretation that there is nothing here to justify the = memset implementation combination: >>>>=20 >>>> SCTLR bit[1]=3D=3D1 >>>>=20 >>>> mixed with >>>>=20 >>>> vst1.64 instructions >>>>=20 >>>> I.e.: one or both needs to change unless some way for forcing = 8-byte alignment is introduced. >>>>=20 >>>> I have not managed to track down anything that would indicate = FreeBSD's intent for SCTLR bit[1]. I do not even know if it is required = by the design to be constant (once initialized). >>>=20 >>>=20 >>> I have (so far) removed the build tool crashes based on adding = -fmax-type-align=3D4 to avoid the misaligned accesses. Details follow. >>>=20 >>> src.conf on amd64 for the rpi2 targeting buildworld/buildkernel now = looks like: >>>=20 >>>> # more ~/src.configs/src.conf.rpi2-clang.amd64-host >>>> TO_TYPE=3Darmv6 >>>> TOOLS_TO_TYPE=3Darm-gnueabi >>>> FROM_TYPE=3Damd64 >>>> TOOLS_FROM_TYPE=3Dx86_64 >>>> VERSION_CONTEXT=3D11.0 >>>> # >>>> KERNCONF=3DRPI2-NODBG >>>> TARGET=3Darm >>>> .if ${.MAKE.LEVEL} =3D=3D 0 >>>> TARGET_ARCH=3D${TO_TYPE} >>>> .export TARGET_ARCH >>>> .endif >>>> # >>>> WITHOUT_CROSS_COMPILER=3D >>>> # >>>> # For WITH_BOOT=3D . . . >>>> # arm-gnueabi-freebsd/bin/ld reports bootinfo.o: relocation = R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a = shared object; recompile with -fPIC >>>> WITHOUT_BOOT=3D >>>> # >>>> WITH_FAST_DEPEND=3D >>>> WITH_LIBCPLUSPLUS=3D >>>> WITH_CLANG=3D >>>> WITH_CLANG_IS_CC=3D >>>> WITH_CLANG_FULL=3D >>>> WITH_LLDB=3D >>>> WITH_CLANG_EXTRAS=3D >>>> # >>>> WITHOUT_LIB32=3D >>>> WITHOUT_GCC=3D >>>> WITHOUT_GNUCXX=3D >>>> # >>>> NO_WERROR=3D >>>> MALLOC_PRODUCTION=3D >>>> #CFLAGS+=3D -DELF_VERBOSE >>>> # >>>> WITH_DEBUG=3D >>>> WITH_DEBUG_FILES=3D >>>> # >>>> # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related = bintutils... >>>> # >>>> #CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc >>>> X_COMPILER_TYPE=3Dclang >>>> CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ >>>> .if ${.MAKE.LEVEL} =3D=3D 0 >>>> XCC=3D/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 >>>> XCXX=3D/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 >>>> XCPP=3D/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 >>>> .export XCC >>>> .export XCXX >>>> .export XCPP >>>> XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as >>>> XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar >>>> XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld >>>> XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm >>>> XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy >>>> XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump >>>> XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib >>>> XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size >>>> #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings >>>> XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings >>>> .export XAS >>>> .export XAR >>>> .export XLD >>>> .export XNM >>>> .export XOBJCOPY >>>> .export XOBJDUMP >>>> .export XRANLIB >>>> .export XSIZE >>>> .export XSTRINGS >>>> .endif >>>> # >>>> # Host compiler stuff: >>>> .if ${.MAKE.LEVEL} =3D=3D 0 >>>> CC=3D/usr/bin/clang -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin >>>> CXX=3D/usr/bin/clang++ -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin >>>> CPP=3D/usr/bin/clang-cpp = -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin >>>> .export CC >>>> .export CXX >>>> .export CPP >>>> AS=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/as >>>> AR=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ar >>>> LD=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ld >>>> NM=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/nm >>>> OBJCOPY=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/objcopy >>>> OBJDUMP=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/objdump >>>> RANLIB=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ranlib >>>> SIZE=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/size >>>> #NO-SUCH: STRINGS=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/strings= >>>> STRINGS=3D/usr/local/bin/${TOOLS_FROM_TYPE}-freebsd-strings >>>> .export AS >>>> .export AR >>>> .export LD >>>> .export NM >>>> .export OBJCOPY >>>> .export OBJDUMP >>>> .export RANLIB >>>> .export SIZE >>>> .export STRINGS >>>> .endif >>>=20 >>> make.conf for during the on-rpi2 port builds now looks like: >>>=20 >>>> $ more /etc/make.conf >>>> WRKDIRPREFIX=3D/usr/obj/portswork >>>> WITH_DEBUG=3D >>>> WITH_DEBUG_FILES=3D >>>> MALLOC_PRODUCTION=3D >>>> # >>>> TO_TYPE=3Darmv6 >>>> TOOLS_TO_TYPE=3Darm-gnueabi >>>> CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ >>>> .if ${.MAKE.LEVEL} =3D=3D 0 >>>> CC=3D/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 >>>> CXX=3D/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 >>>> CPP=3D/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 >>>> .export CC >>>> .export CXX >>>> .export CPP >>>> AS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as >>>> AR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar >>>> LD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld >>>> NM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm >>>> OBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy >>>> OBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump >>>> RANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib >>>> SIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size >>>> #NO-SUCH: STRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings >>>> STRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings >>>> .export AS >>>> .export AR >>>> .export LD >>>> .export NM >>>> .export OBJCOPY >>>> .export OBJDUMP >>>> .export RANLIB >>>> .export SIZE >>>> .export STRINGS >>>> .endif >>>=20 >>>=20 >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> freebsd-toolchain@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >>> To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" >=20 >=20 >=20 From owner-freebsd-arm@freebsd.org Mon Dec 28 12:40:57 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50722A52DA3 for ; Mon, 28 Dec 2015 12:40:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (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 0CE35146E for ; Mon, 28 Dec 2015 12:40:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15910 invoked from network); 28 Dec 2015 12:41:02 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Dec 2015 12:41:02 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 28 Dec 2015 07:40:53 -0500 (EST) Received: (qmail 12581 invoked from network); 28 Dec 2015 12:40:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 Dec 2015 12:40:53 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 306291C43A0; Mon, 28 Dec 2015 04:40:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error? From: Mark Millard In-Reply-To: <9DA7895D-B3DE-41FD-900C-EC95BDE19728@dsl-only.net> Date: Mon, 28 Dec 2015 04:40:54 -0800 Cc: freebsd-arm , FreeBSD Toolchain , Ian Lepore , mat@FreeBSD.org, sbruno@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <3DCC9F25-222F-47E2-BA27-F0ED751F13CE@dsl-only.net> References: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@dsl-only.net> <0D81C2CA-BF1C-4C14-B816-A8C5F68715B5@bsdimp.com> <51EB4AAB-BC81-4282-BA4D-D329C41D660B@dsl-only.net> <8B52074F-FDEF-4119-BB04-630F9BE9E6DB@bsdimp.com> <118D2970-4799-46B1-81A1-0101B907C1BE@dsl-only.net> <9DA7895D-B3DE-41FD-900C-EC95BDE19728@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 12:40:57 -0000 On 2015-Dec-28, at 3:33 AM, Mark Millard wrote: > [I have both dropped a bunch of older history and started a new = break.] >=20 > The clang++ Bus Errors are a compiler implementation defect(!), as = shown below. (Presumes they want clang++ to work in contexts where = alignment is required.) In summary: >=20 > The clang++ source code presumes that there are no alignment criteria = to be met for TemplateArgument instances from the "arg buffer" for any = DependentTemplateSpecializationType instance. >=20 >=20 > The details. . . >=20 > I finally have a 11-line example source file (no includes) that = crashes clang++ on the rpi2. (The example is a partial item from = libc++'s .) >=20 >> # more main.cc >> template >> struct __has_rebind >> { >> template static char __test(typename _Xp::template = rebind<_Up>* =3D 0); >> }; >>=20 >> int >> main () >> { >> return 0; >> } >=20 > The backtrace in clang++ looks like: >=20 >> Program terminated with signal 10, Bus error. >> #0 0x00c404d0 in = clang::DependentTemplateSpecializationType::DependentTemplateSpecializatio= nType () >> [New Thread 22a18000 (LWP 100182/)] >> (gdb) bt >> #0 0x00c404d0 in = clang::DependentTemplateSpecializationType::DependentTemplateSpecializatio= nType () >> #1 0x00d86634 in = clang::ASTContext::getDependentTemplateSpecializationType () >> #2 0x00d865d8 in = clang::ASTContext::getDependentTemplateSpecializationType () >> #3 0x00d862d4 in = clang::ASTContext::getDependentTemplateSpecializationType () >> #4 0x00553b7c in clang::Sema::ActOnTypenameType () >> #5 0x0040cb68 in clang::Parser::TryAnnotateTypeOrScopeToken () >> #6 0x00471198 in $a.28 () >> #7 0x00471198 in $a.28 () >> (gdb) x/1i 0x00c404d0 >> 0xc404d0 = <_ZN5clang35DependentTemplateSpecializationTypeC2ENS_21ElaboratedTypeKeywo= rdEPNS_19NestedNameSpecifierEPKNS_14IdentifierInfoEjPKNS_16TemplateArgumen= tENS_8QualTypeE+356>:=09 >> vst1.64 {d16-d17}, [r4]! >> (gdb) info all-registers >> r0 0xbfbf9778 -1077962888 >> r1 0x22ac59c4 581720516 >> r2 0xc45ff8 12869624 >> r3 0x2 2 >> r4 0x22ac59ac 581720492 > . . . >=20 > The code involved is from lib/AST/Type.cpp : >=20 >> = DependentTemplateSpecializationType::DependentTemplateSpecializationType( >> ElaboratedTypeKeyword Keyword, >> NestedNameSpecifier *NNS, const = IdentifierInfo *Name, >> unsigned NumArgs, const TemplateArgument = *Args, >> QualType Canon) >> : TypeWithKeyword(Keyword, DependentTemplateSpecialization, Canon, = true, true, >> /*VariablyModified=3D*/false, >> NNS && NNS->containsUnexpandedParameterPack()), >> NNS(NNS), Name(Name), NumArgs(NumArgs) { >> assert((!NNS || NNS->isDependent()) && >> "DependentTemplateSpecializatonType requires dependent = qualifier"); >> for (unsigned I =3D 0; I !=3D NumArgs; ++I) { >> if (Args[I].containsUnexpandedParameterPack()) >> setContainsUnexpandedParameterPack(); >>=20 >> new (&getArgBuffer()[I]) TemplateArgument(Args[I]); >> } >> } >=20 > The failing code is for the "placement new" in the loop: >=20 > A) &getArgBuffer()[I] is not always an address for which the vst1.64 = instruction gets an aligned address. >=20 > but. . . >=20 > B) TemplateArgument(Args[I])'s copy construction activity has code = (such as the vst1.64) requiring a specific alignment when SCTLR = bit[1]=3D=3D1. >=20 > C) Nothing here has any explicitly packed data structures. >=20 > As for (A): >=20 >> class DependentTemplateSpecializationType : >> public TypeWithKeyword, public llvm::FoldingSetNode { >> . . . >> const TemplateArgument *getArgBuffer() const { >> return reinterpret_cast(this+1); >> } >> TemplateArgument *getArgBuffer() { >> return reinterpret_cast(this+1); >> } >=20 > clang++ is over-allocating the space for the = DependentTemplateSpecializationType objects and using the extra space = that is afterwards to hold (a somewhat C-style array of) = TemplateArgument instances. But the logic for this does nothing explicit = about alignment of the TemplateArgument instance pointers, not even = partially via explicitly controlling = sizeof(DependentTemplateSpecializationType). >=20 > This code does not explicitly force any specific minimum = TemplateArgument alignment, other than 1. >=20 > Separately there is the issue that the code produced did not treat the = pointers returned from getArgBuffer() methods as "opaque pointer" = examples but they are. Having compiled with -fmax-type-align=3D4 the = code should have not have required 8 byte alignment (vst1.64). It should = have produced code that required 4 (or 2 or 1). Quoting for = -fmax-type-align=3D?: >=20 >> Instruct the code generator to not enforce a higher alignment than = the given number (of bytes) when accessing memory via an opaque pointer = or reference >=20 >=20 > Those pointers certainly are opaque and should be treated as such. The = "reinterpret_cast" use is a big clue that clang++ should respect. >=20 > In other words: I see two clang++ defects in the overall evidence, one = of which directly leads to the Bus Errors being possible. >=20 > The script of the buildworld/buildkernel shows that -fmax-type-align=3D4= -mno-unaligned-access were both used to compile the Type.cpp source = file: >=20 >> --- Type.o --- >> /usr/bin/clang++ -target armv6--freebsd11.0-gnueabi -march=3Darmv7a = -fmax-type-align=3D4 -mno-unaligned-access -target = armv6-gnueabi-freebsd11.0 --sysroot=3D/usr/obj/clang/arm.armv6/usr/src/tmp= -B/usr/local >> /arm-gnueabi-freebsd/bin/ = --sysroot=3D/usr/obj/clang/arm.armv6/usr/src/tmp = -B/usr/local/arm-gnueabi-freebsd/bin/ -O -pipe -mfloat-abi=3Dsoftfp = -I/usr/src/lib/clang/libclangast/../../../contrib/llvm/inclu >> de = -I/usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include= = -I/usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST= -I. -I/usr/src/lib/clang/libclangast/../../../c >> ontrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD = -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT = -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFA >> ULT_TARGET_TRIPLE=3D\"armv6-gnueabi-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"armv6-unknown-freebsd11.0\" = -DDEFAULT_SYSROOT=3D\"\" -MD -MP -MF.depend.Type.o -MTType.o = -Qunused-arguments -std=3Dc++11 -fno-exceptio >> ns -fno-rtti -stdlib=3Dlibc++ -Wno-c++11-extensions -c = /usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/T= ype.cpp -o Type.o >=20 > clang++ may well have other examples of such things in other classes. = I have not looked. I should have mentioned that sizeof(TemplateArgument) also needs to be = controlled in order to have the notation &getArgBuffer()[I] maintain = alignment in its results when &getArgBuffer()[0] is well aligned. The = earlier material focused on just &getArgBuffer()[0] in how it was = presented. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Dec-28, at 12:01 AM, Mark Millard wrote: >=20 >=20 > On 2015-Dec-26, at 8:45 AM, Warner Losh wrote: >=20 >> Thanks, it sounds like I fixed a bug, but there=E2=80=99s more. >>=20 >> What were the specific port so I can test it here? >>=20 >> And to be clear, this is a buildworld on the RPi 2 using the = cross-built world with CPUTYPE=3Darmv7a or some such, right? >>=20 >> Warner >>=20 >>> On Dec 25, 2015, at 9:32 PM, Mark Millard = wrote: >>>=20 >>> [I am again breaking off another section of older material.] >>>=20 >>> Mixed news I'm afraid. >>>=20 >>> The specific couple of ports that I attempted did build, the same = ones that originally got the Bus Error in ar using (indirectly) _fseeko = and memset that I reported. So I expect that you fixed one error. >>>=20 >>> But when I tried to buildworld, clang++ 3.7 processing = usr/src/lib/clang/libllvmtablegen/ materials quickly got a Bus Error at = nearly the same type of instruction (it has a "!" below that the earlier = one did not), but with r4 holding the misaligned address this time: >>>=20 >>>> --- _bootstrap-tools-lib/clang/libllvmsupport --- >>>> --- APFloat.o --- >>>> clang++: error: unable to execute command: Bus error (core dumped) >>>> . . . >>>> # gdb clang++ usr/src/lib/clang/libllvmtablegen/clang++.core >>>> . . . >>>> Core was generated by `clang++'. >>>> Program terminated with signal 10, Bus error. >>>> #0 0x00c3bb9c in = clang::DependentTemplateSpecializationType::DependentTemplateSpecializatio= nType () >>>> [New Thread 22a18000 (LWP 100128/)] >>>> (gdb) x/40i 0x00c3bb60 >>>> . . . >>>> 0xc3bb9c = <_ZN5clang35DependentTemplateSpecializationTypeC2ENS_21ElaboratedTypeKeywo= rdEPNS_19NestedNameSpecifierEPKNS_14IdentifierInfoEjPKNS_16TemplateArgumen= tENS_8QualTypeE+356>: >>>> vst1.64 {d16-d17}, [r4]! >>>> . . . >>>> (gdb) info all-registers >>>> r0 0xbfbf81a8 -1077968472 >>>> r1 0x22f07e14 586186260 >>>> r2 0xc416bc 12850876 >>>> r3 0x2 2 >>>> r4 0x22f07dfc 586186236 >>>> . . . >>>=20 >>>=20 >>> Thus it appears that there is more code around that likely generates = pointers not aligned so to allow the code generation that is in use for = what is pointed to. >>>=20 >>> At this point I have no clue if the issue is just inside clang = itself vs. if it is in something that clang is layered on top of. Nor if = there is just one bad thing or many. >>>=20 >>> Note: I had not yet tried buildworld/buildkernel for the context of = the "-f" option that I was experimenting with earlier. So I do not have = a direct compare and contrast at this point. >=20 > Somehow I did not notice your E-mail at the time. Meanwhile I've more = evidence. . . >=20 > [Initial context for notes: Before updating to 11.0-CURRENT -r292756 = and its clang/clang++ 3.7.1.] >=20 > Example c++ program that clang++ got an internal Bus Error for: >=20 >> # more main.cc >> #include >> int >> main () >> { >> std::ostream *o; return 0; >> } >=20 > Of course the include makes the source being processed non-trivial. >=20 > Going in a different direction. . . dmesg -a | grep "core dumped" on = the rpi2 showed: >=20 >> pid 22238 (msgfmt), uid 0: exited on signal 11 (core dumped) >> pid 22250 (xgettext), uid 0: exited on signal 11 (core dumped) >> pid 22259 (msgmerge), uid 0: exited on signal 11 (core dumped) >> pid 26149 (msgfmt), uid 0: exited on signal 11 (core dumped) >> pid 26161 (xgettext), uid 0: exited on signal 11 (core dumped) >> pid 26170 (msgmerge), uid 0: exited on signal 11 (core dumped) >> pid 28826 (c++), uid 0: exited on signal 10 (core dumped) >> pid 29202 (c++), uid 0: exited on signal 10 (core dumped) >> pid 29282 (c++), uid 0: exited on signal 10 (core dumped) >> pid 29292 (clang++), uid 0: exited on signal 10 (core dumped) >=20 > Only the c++/clang++ contexts (same but for name) seemed to be leaving = .core files behind. >=20 > The older log files also showed examples like the following from ports = building activity: >=20 >> /var/log/dmesg.today:pid 18763 (conftest), uid 0: exited on signal 11 = (core dumped) >> /var/log/dmesg.today:pid 18916 (conftest), uid 0: exited on signal 11 = (core dumped) >=20 > (The original ar that I started with showed as well, the records went = back that far at the time.) >=20 > [New -r292756 context. . .] >=20 > After the above I updated to: >=20 >> $ freebsd-version -ku; uname -aKU >> 11.0-CURRENT >> 11.0-CURRENT >> FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r292756M: Sun Dec = 27 02:55:57 PST 2015 = root@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm = 1100092 1100092 >=20 > in order to pick up clang 3.7.1. I used -fmax-type-align=3D4 = -mno-unaligned-access in the src.conf file for the buildworld = buildkernel amd64->rpi2 cross build before installing both parts on the = rpi2 media. >=20 > On the rpi2 itself the resulting c++/clang++ still gets Bus Error = during buildworld despite the use of -fmax-type-align=3D4 = -mno-unaligned-acces in the amd64 hosted cross build (and in the rpi2 = attempted rebuild). An example crash report is: >=20 >> /usr/bin/clang++ -B/usr/local/arm-gnueabi-freebsd/bin -march=3Darmv7a = -fmax-type-align=3D4 -mno-unaligned-access -O -pipe -mfloat-abi=3Dsoftfp = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/incl= ude = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support = -I. = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/= include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv6-gnueabi-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"armv6-unknown-freebsd11.0\" = -DDEFAULT_SYSROOT=3D\"\" -MD -MP -MF.depend.APFloat.o -MTAPFloat.o = -Qunused-arguments = -I/usr/obj/clang/arm.armv6/usr/src/tmp/legacy/usr/include -std=3Dc++11 = -fno-exceptions -fno-rtti -stdlib=3Dlibc++ -Wno-c++11-extensions -c = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloa= t.cpp -o APFloat.o >> clang++: error: unable to execute command: Bus error (core dumped) >> clang++: error: clang frontend command failed due to signal (use -v = to see invocation) >> FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 >> Target: armv6--freebsd11.0-gnueabi >> Thread model: posix >> clang++: note: diagnostic msg: PLEASE submit a bug report to = https://bugs.freebsd.org/submit/ and include the crash backtrace, = preprocessed source, and associated run script. >> clang++: note: diagnostic msg:=20 >> ******************** >>=20 >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> Preprocessed source(s) and associated run script(s) are located at: >> clang++: note: diagnostic msg: /tmp/APFloat-04544c.cpp >> clang++: note: diagnostic msg: /tmp/APFloat-04544c.sh >> clang++: note: diagnostic msg:=20 >>=20 >> ******************** >> *** Error code 254 >>=20 >> Stop. >> make[3]: stopped in /usr/src/lib/clang/libllvmsupport >> *** Error code 1 >=20 > An earlier -j 6 buildworld had failures for ARMBuildAttrs, APSInt, = APInt, and Error before stopping, in addition to the APFloat indicated = above (no -j makes for easier reading above): >=20 >> # ls -lt /tmp >> total 41516 >> -rw-r--r-- 1 root wheel 4057 Dec 28 03:05 APFloat-04544c.sh >> -rw-r--r-- 1 root wheel 2155452 Dec 28 03:05 APFloat-04544c.cpp >> -rw-r--r-- 1 root wheel 4081 Dec 28 02:53 = ARMBuildAttrs-432569.sh >> -rw-r--r-- 1 root wheel 1276912 Dec 28 02:53 = ARMBuildAttrs-432569.cpp >> -rw-r--r-- 1 root wheel 3997 Dec 28 02:53 APSInt-a2927e.sh >> -rw-r--r-- 1 root wheel 1943445 Dec 28 02:53 APSInt-a2927e.cpp >> -rw-r--r-- 1 root wheel 3985 Dec 28 02:53 APInt-d0389a.sh >> -rw-r--r-- 1 root wheel 2115595 Dec 28 02:53 APInt-d0389a.cpp >> -rw-r--r-- 1 root wheel 4009 Dec 28 02:53 APFloat-33be1b.sh >> -rw-r--r-- 1 root wheel 2155452 Dec 28 02:53 APFloat-33be1b.cpp >> -rw-r--r-- 1 root wheel 4001 Dec 28 02:53 Error-777068.sh >> -rw-r--r-- 1 root wheel 1925065 Dec 28 02:53 Error-777068.cpp >=20 > The earlier "iostream" program example also still gets its Bus Error = during its clang++ based compilation in this new -r292756 context. >=20 > The above -r292756 material avoids involving ports software with its = own set of additional questions, compilers, tools, etc.: it sticks to = buildworld/buildkernel material (and never gets to buildkernel). >=20 > When I tried -j 5 buildkernel by itself on the rpi2 there were no Bus = Errors, no Segmentation Faults, and no core dumps. The buildkernel took = about 51 minutes. (I've not tried installing what it built.) >=20 > (I have a SSD on a USB hub in use for world/root on the rpi2. The = /etc/fstab on the micro-SD lists / as mounting from the SSD instead. I = installkernel and installworld via the amd64 context to both the = micro-SD and the SSD so that they track. I can boot from just the = micro-SD if I want to but normally involve the SSD.) >=20 > Another kind of experiment would be to omit -fmax-type-align=3D4 but = use -mno-unaligned-access (for handling any packed data structures) and = see if buildkernel can still finish on the rpi2 (if enough of the = amd64->rpi2 buildworld still operates on the rpi2 to allow the test). >=20 > A potential experiment for buildworld would be to use = -fmax-type-align=3D1 with -mno-unaligned-access as the amd64->rpi2 cross = build context. A misalignment Bus Error from that context might well be = a clang++ code generation error of not paying attention to the alignment = rules where clang++ should. >=20 > A potentially interesting (but independent) set of warnings during the = buildkernel was: >=20 >> WARNING: hwpmc_mod.c: enum pmc_event has too many values: 2588 > 1023 >> WARNING: hwpmc_logging.c: enum pmc_event has too many values: 2588 > = 1023 >> WARNING: hwpmc_soft.c: enum pmc_event has too many values: 2588 > = 1023 >> WARNING: hwpmc_arm.c: enum pmc_event has too many values: 2588 > 1023 >=20 > (I've not investigated.) >=20 >=20 >=20 > Before this -r292756 update the following ports seemed to have built = without generating core dumps or Bus Error reports or other such in the = process: >=20 > devel/gettext-tools > devel/gmake-lite > devel/p5-Locale-gettext > lang/perl5.22 > security/sudo >=20 > Note that I did not use make.conf to force -f. . . and -m. . . for = these. But the test was if they could build, not if they operated = correctly when built. >=20 > My guess is that they are primarily C instead of C++ and/or happen to = avoid the parts of C++ where clang++ is having internal data structure = alignment problems vs. SCTLR bit[1]=3D=3D1. >=20 > Generally the pkg installs on the rpi2 seemed to have been operating = okay. But they do nto test compiling/linking with the system = clang/clang++ involved. >=20 > In general building ports can have other issues that block completion = so I had not tried much in that direction and happened to pick on a few = things that worked (see above). Getting through a self-hosting rpi2 = buildworld buildkernel first likely is a better path before involving = ports. >=20 > But my way of working has involved using devel/arm-gnueabi-binutils , = which seemed to build and work fine. >=20 >=20 > One thing of note from all my rpi2 builds: I've learned to avoid doing = a "svnlite status /usr/src/" and similar commands. Fairly frequently = they do not complete and each existing ssh connection to the rpi2 quits = responding once some new program is attempted from the connection. The = same for directly at the rpi2 (via USB devices). >=20 > Unfortunately /var/log/messages only shows the following boot, no = messages from the hang-up context. I'd guess that USB (and other such?) = communication stopped operating. >=20 >=20 >=20 > The src.conf for on the rpi2 has (the amd64->rpi2 cross compile was = very similar but the amd64-host-targets-self clang/clang++ commands do = not need the -f. . . and -m. . . ): >=20 >> TO_TYPE=3Darmv6 >> TOOLS_TO_TYPE=3Darm-gnueabi >> FROM_TYPE=3D${TO_TYPE} >> TOOLS_FROM_TYPE=3D${TOOLS_TO_TYPE} >> VERSION_CONTEXT=3D11.0 >> # >> KERNCONF=3DRPI2-NODBG >> TARGET=3Darm >> .if ${.MAKE.LEVEL} =3D=3D 0 >> TARGET_ARCH=3D${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> WITHOUT_CROSS_COMPILER=3D >> # >> # For WITH_BOOT=3D . . . (amd64 cross compile context) >> # arm-gnueabi-freebsd/bin/ld reports bootinfo.o: relocation = R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a = shared object; recompile with -fPIC=20 >> WITHOUT_BOOT=3D >> # >> WITH_FAST_DEPEND=3D >> WITH_LIBCPLUSPLUS=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_LLDB=3D >> WITH_CLANG_EXTRAS=3D >> # >> WITHOUT_LIB32=3D >> WITHOUT_GCC=3D >> WITHOUT_GNUCXX=3D >> # >> NO_WERROR=3D >> MALLOC_PRODUCTION=3D >> #CFLAGS+=3D -DELF_VERBOSE >> # >> WITH_DEBUG=3D >> WITH_DEBUG_FILES=3D >> # >> # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related = bintutils... >> # >> #CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc >> X_COMPILER_TYPE=3Dclang >> CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ >> .if ${.MAKE.LEVEL} =3D=3D 0 >> XCC=3D/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> XCXX=3D/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> XCPP=3D/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> .export XCC >> .export XCXX >> .export XCPP >> XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as >> XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar >> XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld >> XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm >> XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy >> XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump >> XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib >> XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size >> #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings >> XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings >> .export XAS >> .export XAR >> .export XLD >> .export XNM >> .export XOBJCOPY >> .export XOBJDUMP >> .export XRANLIB >> .export XSIZE >> .export XSTRINGS >> .endif >> # >> # =46rom clang (via system)... >> # >> .if ${.MAKE.LEVEL} =3D=3D 0 >> CC=3D/usr/bin/clang -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> CXX=3D/usr/bin/clang++ -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> CPP=3D/usr/bin/clang-cpp -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> .export CC >> .export CXX >> .export CPP >> .endif >> # >> # >> # TOOLS_FROM_TYPE binutils from xtoolchain like context... >> # >> .if ${.MAKE.LEVEL} =3D=3D 0 >> AS=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/as >> AR=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ar >> LD=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ld >> NM=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/nm >> OBJCOPY=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/objcopy >> OBJDUMP=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/objdump >> RANLIB=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ranlib >> SIZE=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/size >> #NO-SUCH: STRINGS=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/strings >> STRINGS=3D/usr/local/bin/${TOOLS_FROM_TYPE}-freebsd-strings >> .export AS >> .export AR >> .export LD >> .export NM >> .export OBJCOPY >> .export OBJDUMP >> .export RANLIB >> .export SIZE >> .export STRINGS >> .endif >=20 > This technique does require devel/arm-gnueabi-binutils to have been = built and operating okay on amd64 and later on the rpi2. So far I've no = hints of any problems in that area. >=20 >=20 >=20 > The RPI2-NODBG config is shown below: >=20 >> # more /usr/src/sys/arm/conf/RPI2-NODBG=20 >> ident RPI2-NODBG >>=20 >> include "RPI2" >>=20 >> makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >> options ALT_BREAK_TO_DEBUGGER >> #options VERBOSE_SYSINIT # Enable verbose sysinit = messages >>=20 >> options KDB # Enable kernel debugger = support >>=20 >> # For minimum debugger support (stable branch) use: >> #options KDB_TRACE # Print a stack trace for a = panic >> options DDB # Enable the kernel debugger >>=20 >> nooptions INVARIANTS # Enable calls of extra = sanity checking >> nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS >> nooptions WITNESS # Enable checks to detect = deadlocks and cycles >> nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed >> nooptions DIAGNOSTIC >=20 >=20 > Most of my /usr/src/ tailoring is tied to powerpc and powerpc64 = issues: >=20 >> # svnlite status /usr/src/ >> ? /usr/src/.snap >> M /usr/src/contrib/libcxxrt/guard.cc >> M /usr/src/lib/csu/powerpc64/Makefile >> M /usr/src/lib/libc/stdio/findfp.c >> ? /usr/src/lib/libc/stdio/findfp.c.orig >> ? /usr/src/restoresymtable >> ? /usr/src/sys/arm/conf/RPI2-NODBG >> M /usr/src/sys/boot/ofw/Makefile.inc >> M /usr/src/sys/boot/powerpc/Makefile.inc >> M /usr/src/sys/boot/uboot/Makefile.inc >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG >> ? /usr/src/sys/powerpc/conf/GENERICvtsc >> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG >> M /usr/src/sys/powerpc/ofw/ofw_machdep.c >=20 > lib/libc/stdio/findfp.c has the patch I was asked to test. >=20 > contrib/libcxxrt/guard.cc is to avoid bad C++ source code (use of = C11-specific notation in C++ that is reported syntax errors in = powerpc64-xtoolchain-gcc/powerpc64-gcc compilation contexts): >=20 >> # svnlite diff /usr/src/contrib/libcxxrt/guard.cc >> Index: /usr/src/contrib/libcxxrt/guard.cc >> =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 >> --- /usr/src/contrib/libcxxrt/guard.cc (revision 292756) >> +++ /usr/src/contrib/libcxxrt/guard.cc (working copy) >> @@ -101,7 +101,7 @@ >> uint32_t init_half; >> uint32_t lock_half; >> } guard_t; >> -_Static_assert(sizeof(guard_t) =3D=3D sizeof(uint64_t), ""); >> +//_Static_assert(sizeof(guard_t) =3D=3D sizeof(uint64_t), ""); >> static const uint32_t LOCKED =3D 1; >> static const uint32_t INITIALISED =3D static_cast(1) << = 24; >> # endif >=20 > The sys/boot/. . . examples are just use of -Wl, notation in LDFLAGS = where the original notation was rejected, such as: >=20 >> # svnlite diff /usr/src/sys/boot/uboot/Makefile.inc >> Index: /usr/src/sys/boot/uboot/Makefile.inc >> =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 >> --- /usr/src/sys/boot/uboot/Makefile.inc (revision 292756) >> +++ /usr/src/sys/boot/uboot/Makefile.inc (working copy) >> @@ -2,7 +2,7 @@ >>=20 >> .if ${MACHINE_ARCH} =3D=3D "powerpc64" >> CFLAGS+=3D -m32 -mcpu=3Dpowerpc >> -LDFLAGS+=3D -m elf32ppc_fbsd >> +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd >> .endif >>=20 >> .include "../Makefile.inc" >=20 > All 3 are powerpc64 specific changes. >=20 > =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Dec 28 13:56:38 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED3F6A54777 for ; Mon, 28 Dec 2015 13:56:38 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DB181C6B for ; Mon, 28 Dec 2015 13:56:37 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id tBSDu1X5035917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Dec 2015 14:56:08 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id tBSDttUd003473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2015 14:55:55 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id tBSDttT7047044; Mon, 28 Dec 2015 14:55:55 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id tBSDtsHN047043; Mon, 28 Dec 2015 14:55:54 +0100 (CET) (envelope-from ticso) Date: Mon, 28 Dec 2015 14:55:54 +0100 From: Bernd Walter To: Matthieu Volat Cc: freebsd-arm@freebsd.org Subject: Re: Raspberry Pi and WaveShare SpotPear LCD screens Message-ID: <20151228135554.GA45251@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <36285EFC-0739-4A93-B22D-C22B7BDEE16D@alkumuna.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <36285EFC-0739-4A93-B22D-C22B7BDEE16D@alkumuna.eu> X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 13:56:39 -0000 On Mon, Dec 28, 2015 at 11:16:29AM +0100, Matthieu Volat wrote: > Hi everybody, > > I brought a WaveShare SpotPear LCD screen for my Raspberry Pi B+ board, having seen on the wiki page that LCD screen were working. > > But this kind of screen uses the GPIO connectors rather than the dedicated display bus. It seems that even with Raspbian, it needs a special image to work. > > The question is: does anybody have experience with those screens, would it simply require DFT modifications or something more? I cannot find sources on the supplement CD provided in the package. Basicly they run with fixed configuration HDMI dummy output and then copy the framebuffer over SPI to the display, which has it's own displaymemory. The board has some shift registers, so I'm guessing that the panel itself uses a memory bus. At least one GPIOs is used for backlight and I think there is an enable. The touch controller is connected to I2C and needs it's own driver too. Havn't worked out the details. Easiest for you would be to use one of their bigger HDMI displays. They have 5" and 7" and recently also 10.x". Be aware that they have two 5" - one is connected to the GPIO header for Power and I²C to run the touch controller. The other one uses USB cables and an STM32 controller to run the touch controller as an USB device - not sure if it is a standard device, since I'd tested it with a Linux desktop and it didn't run out of the box. I havn't run any FreeBSD with display yet. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Mon Dec 28 14:08:09 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 695CFA54C51; Mon, 28 Dec 2015 14:08:09 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id 310EC1EEF; Mon, 28 Dec 2015 14:08:08 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from zapp.Home (unknown [90.200.119.55]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id 927D3D7A17; Mon, 28 Dec 2015 14:07:32 +0000 (UTC) Date: Mon, 28 Dec 2015 14:07:29 +0000 From: Andrew Turner To: Mark Millard Cc: Warner Losh , mat@FreeBSD.org, freebsd-arm , FreeBSD Toolchain , Ian Lepore Subject: Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error? Message-ID: <20151228140729.565c9dc6@zapp.Home> In-Reply-To: <9DA7895D-B3DE-41FD-900C-EC95BDE19728@dsl-only.net> References: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@dsl-only.net> <0D81C2CA-BF1C-4C14-B816-A8C5F68715B5@bsdimp.com> <51EB4AAB-BC81-4282-BA4D-D329C41D660B@dsl-only.net> <8B52074F-FDEF-4119-BB04-630F9BE9E6DB@bsdimp.com> <118D2970-4799-46B1-81A1-0101B907C1BE@dsl-only.net> <9DA7895D-B3DE-41FD-900C-EC95BDE19728@dsl-only.net> X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 14:08:09 -0000 On Mon, 28 Dec 2015 03:33:09 -0800 Mark Millard wrote: ... > The failing code is for the "placement new" in the loop: > > A) &getArgBuffer()[I] is not always an address for which the vst1.64 > instruction gets an aligned address. > > but. . . > > B) TemplateArgument(Args[I])'s copy construction activity has code > (such as the vst1.64) requiring a specific alignment when SCTLR > bit[1]==1. > > C) Nothing here has any explicitly packed data structures. The bug is we enable the alignment checks in the kernel. Compilers assume there are no alignment checks on ARMv7. We have taught gcc to generate worse code on FreeBSD because of this. There was some concern about reading non-naturally aligned data in the kernel not being atomic, this could be checked by, in debug configurations, enabling alignment checks on entry to the kernel and disabling them on exit. We could also have a flag for clang to tell it we are in the kernel, there is already something similar for iOS. Andrew From owner-freebsd-arm@freebsd.org Mon Dec 28 14:26:32 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63534A523CA; Mon, 28 Dec 2015 14:26:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF51D1B36; Mon, 28 Dec 2015 14:26:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tBSEQJUI099952 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 28 Dec 2015 16:26:20 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tBSEQJUI099952 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tBSEQJ0p099951; Mon, 28 Dec 2015 16:26:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 28 Dec 2015 16:26:19 +0200 From: Konstantin Belousov To: Andrew Turner Cc: Mark Millard , mat@FreeBSD.org, freebsd-arm , FreeBSD Toolchain , Ian Lepore Subject: Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error? Message-ID: <20151228142619.GR3625@kib.kiev.ua> References: <0D81C2CA-BF1C-4C14-B816-A8C5F68715B5@bsdimp.com> <51EB4AAB-BC81-4282-BA4D-D329C41D660B@dsl-only.net> <8B52074F-FDEF-4119-BB04-630F9BE9E6DB@bsdimp.com> <118D2970-4799-46B1-81A1-0101B907C1BE@dsl-only.net> <9DA7895D-B3DE-41FD-900C-EC95BDE19728@dsl-only.net> <20151228140729.565c9dc6@zapp.Home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151228140729.565c9dc6@zapp.Home> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 14:26:32 -0000 On Mon, Dec 28, 2015 at 02:07:29PM +0000, Andrew Turner wrote: > There was some concern about reading non-naturally aligned data in the > kernel not being atomic, this could be checked by, in debug > configurations, enabling alignment checks on entry to the kernel and > disabling them on exit. We could also have a flag for clang to tell it > we are in the kernel, there is already something similar for iOS. What do you mean ? Non-aligned reads are non-atomic on all known arches, including x86. In the Core2 time this non-atomicity became easily observable due to the microacrhitecture changes, which happens simultaneously with a mis-aligned bug in DPCPU code. I do not think we ever depend on the atomicity of the unaligned reads in MI and in x86 MD code since then, why would arm differ there ? From owner-freebsd-arm@freebsd.org Mon Dec 28 15:41:20 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E5FBA53C57 for ; Mon, 28 Dec 2015 15:41:20 +0000 (UTC) (envelope-from mazhe@alkumuna.eu) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF69E1384 for ; Mon, 28 Dec 2015 15:41:19 +0000 (UTC) (envelope-from mazhe@alkumuna.eu) Received: from yggdrasil.alkumuna.eu (unknown [IPv6:2a01:e35:8a74:6e70:232:36ff:fe5c:3a87]) by smtp1-g21.free.fr (Postfix) with ESMTPS id BFC8C9400FB; Mon, 28 Dec 2015 16:40:45 +0100 (CET) Received: from [192.168.11.10] (ADijon-656-1-22-237.w90-13.abo.wanadoo.fr [90.13.37.237]) (authenticated bits=0) by yggdrasil.alkumuna.eu (8.15.2/8.15.2) with ESMTPSA id tBSFf4QI051846 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Dec 2015 16:41:11 +0100 (CET) (envelope-from mazhe@alkumuna.eu) Subject: Re: Raspberry Pi and WaveShare SpotPear LCD screens Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_844AECA7-B803-4497-ACB4-A48FCE20490C"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 From: Matthieu Volat In-Reply-To: <20151228135554.GA45251@cicely7.cicely.de> Date: Mon, 28 Dec 2015 16:40:59 +0100 Cc: freebsd-arm@freebsd.org Message-Id: References: <36285EFC-0739-4A93-B22D-C22B7BDEE16D@alkumuna.eu> <20151228135554.GA45251@cicely7.cicely.de> To: ticso@cicely.de X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 15:41:20 -0000 --Apple-Mail=_844AECA7-B803-4497-ACB4-A48FCE20490C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > Le 28 d=E9c. 2015 =E0 14:55, Bernd Walter a = =E9crit : > > [...] >=20 > Basicly they run with fixed configuration HDMI dummy output and then > copy the framebuffer over SPI to the display, which has it's own > displaymemory. > The board has some shift registers, so I'm guessing that the panel > itself uses a memory bus. > At least one GPIOs is used for backlight and I think there is an = enable. > The touch controller is connected to I2C and needs it's own driver = too. > Havn't worked out the details. > Easiest for you would be to use one of their bigger HDMI displays. > They have 5" and 7" and recently also 10.x". > Be aware that they have two 5" - one is connected to the GPIO header > for Power and I=B2C to run the touch controller. > The other one uses USB cables and an STM32 controller to run the touch > controller as an USB device - not sure if it is a standard device, > since I'd tested it with a Linux desktop and it didn't run out of the = box. > I havn't run any FreeBSD with display yet. >=20 Thanks, that's a very good summary. So if I understand well, we'd need = to add a whole new class of framebuffer. That would be a good exercise, = but I fear not having enough time/knowledge to do so... not soon at = least. Thank you very much, I'll try to read a bit more about the fb devices in = /usr/src/arm/bcm2835, as well as look a bit at the fbtft module in Linux = staging area. -- Matthieu Volat --Apple-Mail=_844AECA7-B803-4497-ACB4-A48FCE20490C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlaBWBAACgkQ+ENDeYKZi35/0ACeKi1Xjd/MfkzNOfaE9NXnlhnS 1VgAn271Lxe0wbof00dIRs0otoZ0jK0G =z2gw -----END PGP SIGNATURE----- --Apple-Mail=_844AECA7-B803-4497-ACB4-A48FCE20490C-- From owner-freebsd-arm@freebsd.org Mon Dec 28 22:02:03 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50D76A53AB2 for ; Mon, 28 Dec 2015 22:02:03 +0000 (UTC) (envelope-from crees@physics.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 350381829 for ; Mon, 28 Dec 2015 22:02:03 +0000 (UTC) (envelope-from crees@physics.org) Received: by mailman.ysv.freebsd.org (Postfix) id 34DBFA53AB0; Mon, 28 Dec 2015 22:02:03 +0000 (UTC) Delivered-To: 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 34753A53AAF for ; Mon, 28 Dec 2015 22:02:03 +0000 (UTC) (envelope-from crees@physics.org) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by mx1.freebsd.org (Postfix) with ESMTP id CCACA1828 for ; Mon, 28 Dec 2015 22:02:02 +0000 (UTC) (envelope-from crees@physics.org) X-Trace: 259377704/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ON_NET_AUTH_ACCEPTED/Talk_Talk_Customer/2.102.6.73/-4.0/crees@physics.org X-SBRS: -4.0 X-RemoteIP: 2.102.6.73 X-IP-MAIL-FROM: crees@physics.org X-SMTP-AUTH: bayofrum@uwclub.net X-MUA: Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CPCQA2sIFWPEkGZgJeKAECgw9SbYhZtlYmhwdNAQEBAQEBBwEBAQFBP0EQhCIeIj0WGAMCAQIBJwonBgICiC8BCZsaoT4hhlaDeziDOYI2hBkFlwaBDoQyiW1Kg3yCdw4jhTGOOoRuPjQBAQGCZ4ITAQEB X-IPAS-Result: A2CPCQA2sIFWPEkGZgJeKAECgw9SbYhZtlYmhwdNAQEBAQEBBwEBAQFBP0EQhCIeIj0WGAMCAQIBJwonBgICiC8BCZsaoT4hhlaDeziDOYI2hBkFlwaBDoQyiW1Kg3yCdw4jhTGOOoRuPjQBAQGCZ4ITAQEB X-IronPort-AV: E=Sophos;i="5.20,492,1444690800"; d="scan'208";a="259377704" X-IP-Direction: OUT Received: from host-2-102-6-73.as13285.net (HELO pegasus.bayofrum.net) ([2.102.6.73]) by smtp.pipex.tiscali.co.uk with ESMTP; 28 Dec 2015 22:01:54 +0000 Received: from [192.168.1.181] (HESTIA.bayofrum.net [192.168.1.181]) by pegasus.bayofrum.net (Postfix) with ESMTPSA id 8CD3419EA2 for ; Mon, 28 Dec 2015 22:00:36 +0000 (GMT) Message-ID: <5681AD3F.6000202@physics.org> Date: Mon, 28 Dec 2015 21:44:31 +0000 From: Chris Rees User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29 MIME-Version: 1.0 To: arm@FreeBSD.org Subject: Cross building ports amd64/armv6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-bayofrum-MailScanner-Information: Please contact the ISP for more information X-bayofrum-MailScanner-ID: 8CD3419EA2.A9565 X-bayofrum-MailScanner: Found to be clean X-bayofrum-MailScanner-From: crees@physics.org X-Spam-Status: No X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 22:02:03 -0000 Hi all, Got a weird problem (as you'd expect with cross-built ports!) I have a cross-building toolchain made with [1] (irrelevant to this issue), and I'm using poudriere to build ports for my R-Pi. It's mainly working great, save a few issues with ld for which I'm disabling the cross-building tools and using the native ones. The issue I have is with the odd port that tries to install(1) empty files, such as lang/python27 and audio/libvorbis [2]. I can reproduce this by entering the build jail, and *on the wrkdir mount* touching a, installing a b. The wrkdir is created with mdconfig -a -t swap -s 3G by poudriere, and it doesn't happen on the zfs partition that the partition resides on. I've narrowed it down to this ancient optimisation (mmap and write if less than 8M), which is from ~r1000 [3]; if I disable this block of code and just use the code below it (read to buf, write from buf) the problem disappears. Firstly, is this known? Secondly, is it likely to be possible/a priority to fix? It could be anything, but my suspicion is that it's an endian issue, as somehow nw ends up negative (error from line 1181). I could be wrong. Could also somehow be a 64/32bit issue... I'll stop guessing. Does anyone have any ideas please? [crees@pegasus]~% uname -a FreeBSD pegasus.bayofrum.net 10.2-RELEASE-p2 FreeBSD 10.2-RELEASE-p2 #2 r287474: Sat Sep 5 17:56:09 BST 2015 root@pegasus.bayofrum.net:/usr/obj/usr/src/sys/PEGASUS amd64 Chris [1] http://phaq.phunsites.net/2015/10/11/freebsd-on-armv6-cross-compile-performance-optimization-for-poudriere/ [2] https://www.bayofrum.net/pkg/102armv6-default/2015-12-27_22h07m30s/logs/errors/libvorbis-1.3.5,3.log [3] http://svnweb.freebsd.org/base/head/usr.bin/xinstall/xinstall.c?revision=291091&view=markup#l1168 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-arm@freebsd.org Mon Dec 28 22:25:42 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20159A542E2 for ; Mon, 28 Dec 2015 22:25:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0465410A9 for ; Mon, 28 Dec 2015 22:25:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 02233A542E1; Mon, 28 Dec 2015 22:25:42 +0000 (UTC) Delivered-To: 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 DB989A542E0 for ; Mon, 28 Dec 2015 22:25:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8552B10A8 for ; Mon, 28 Dec 2015 22:25:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tBSMPW1g013501 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 29 Dec 2015 00:25:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tBSMPW1g013501 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tBSMPVs7013499; Tue, 29 Dec 2015 00:25:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 29 Dec 2015 00:25:31 +0200 From: Konstantin Belousov To: Chris Rees Cc: arm@FreeBSD.org Subject: Re: Cross building ports amd64/armv6 Message-ID: <20151228222531.GT3625@kib.kiev.ua> References: <5681AD3F.6000202@physics.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5681AD3F.6000202@physics.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 22:25:42 -0000 On Mon, Dec 28, 2015 at 09:44:31PM +0000, Chris Rees wrote: > Hi all, > > Got a weird problem (as you'd expect with cross-built ports!) > > I have a cross-building toolchain made with [1] (irrelevant to this > issue), and I'm using poudriere to build ports for my R-Pi. > > It's mainly working great, save a few issues with ld for which I'm > disabling the cross-building tools and using the native ones. The issue > I have is with the odd port that tries to install(1) empty files, such > as lang/python27 and audio/libvorbis [2]. > > I can reproduce this by entering the build jail, and *on the wrkdir > mount* touching a, installing a b. > > The wrkdir is created with mdconfig -a -t swap -s 3G by poudriere, and > it doesn't happen on the zfs partition that the partition resides on. > I've narrowed it down to this ancient optimisation (mmap and write if > less than 8M), which is from ~r1000 [3]; if I disable this block of code > and just use the code below it (read to buf, write from buf) the problem > disappears. It took an effort to understand what is your problem. Is it EFAULT from something in install(1) ? Does it happen on amd64 system or on arm system ? What are the filesystem types both for the source and destination files locations for failing install ? Also, provide the ktrace -t '+f' / kdump output for the failing install(1) run. > > Firstly, is this known? Secondly, is it likely to be possible/a > priority to fix? It could be anything, but my suspicion is that it's an > endian issue, as somehow nw ends up negative (error from line 1181). I > could be wrong. Could also somehow be a 64/32bit issue... I'll stop > guessing. > > Does anyone have any ideas please? > > [crees@pegasus]~% uname -a > FreeBSD pegasus.bayofrum.net 10.2-RELEASE-p2 FreeBSD 10.2-RELEASE-p2 #2 > r287474: Sat Sep 5 17:56:09 BST 2015 > root@pegasus.bayofrum.net:/usr/obj/usr/src/sys/PEGASUS amd64 > > Chris > > [1] > http://phaq.phunsites.net/2015/10/11/freebsd-on-armv6-cross-compile-performance-optimization-for-poudriere/ > > [2] > https://www.bayofrum.net/pkg/102armv6-default/2015-12-27_22h07m30s/logs/errors/libvorbis-1.3.5,3.log > > [3] > http://svnweb.freebsd.org/base/head/usr.bin/xinstall/xinstall.c?revision=291091&view=markup#l1168 > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Mon Dec 28 23:06:12 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D95D5A54FED for ; Mon, 28 Dec 2015 23:06:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (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 89EBD13A7 for ; Mon, 28 Dec 2015 23:06:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19734 invoked from network); 28 Dec 2015 23:06:05 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 28 Dec 2015 23:06:05 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 28 Dec 2015 18:06:07 -0500 (EST) Received: (qmail 5799 invoked from network); 28 Dec 2015 23:06:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 Dec 2015 23:06:06 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 62CC51C43C4; Mon, 28 Dec 2015 15:06:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: llvm.org's James Molloy on the need for -mno-unaligned-access for SCTLR bit[1]==1 arm contexts From: Mark Millard Date: Mon, 28 Dec 2015 15:06:04 -0800 Cc: freebsd-arm , FreeBSD Toolchain , Konstantin Belousov , Andrew Turner , mat@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ian Lepore , Warner Losh X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 23:06:12 -0000 Begin forwarded message: > From: bugzilla-daemon@llvm.org > Subject: [Bug 25958] FreeBSD 11.0-CURRENT clang++ 3.7.1 gets Bus = Errors during compilation on arm that has SCTLR bit[1]=3D=3D1 (alignment = required) > Date: December 28, 2015 at 1:28:28 PM PST > To: >=20 > James Molloy changed bug 25958=20 > What Removed Added > CC james.molloy@arm.com >=20 > Comment # 2 on bug 25958 from James Molloy > Hi Mark, >=20 > Thanks for raising this. Before checking the specifics of what you = found - did > you compile Clang with -mno-unaligned-access? We will by default = compile > assuming SCTLR.A is 0. -mno-unaligned-access switches this assumption = off and > enables strict alignment mode. >=20 > Cheers, >=20 > James =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Dec 29 09:16:43 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 510A3A541F1; Tue, 29 Dec 2015 09:16:43 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0FDCB1A1A; Tue, 29 Dec 2015 09:16:42 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1aDqOJ-000PQV-J1; Tue, 29 Dec 2015 11:16:27 +0200 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: D-link wireless not detected Date: Tue, 29 Dec 2015 11:16:27 +0200 Message-Id: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> Cc: freebsd-current@FreeBSD.org To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 09:16:43 -0000 Hi All, I have a working tp-link usb (realtek), but can=E2=80=99t get a = d-link(also realtek) to work. usbconfig: ugen0.4: at usbus0, cfg=3D0 = md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (500mA) This is on a raspberry pi running a resent current. cheers & season greetings, danny From owner-freebsd-arm@freebsd.org Tue Dec 29 09:33:54 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 378C4A548C9; Tue, 29 Dec 2015 09:33:54 +0000 (UTC) (envelope-from vbotka@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C99B91272; Tue, 29 Dec 2015 09:33:53 +0000 (UTC) (envelope-from vbotka@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id l65so31271497wmf.3; Tue, 29 Dec 2015 01:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-type; bh=fuoEvXBdRerkC+LyCzuMg6wGbODKBgm89LzoyqRPam0=; b=Ka1HSDsk0HcKlz62t6WO0SUvvzhruAQWdiUOzZDWx15ZIoIzbca+JSBBOXxjwVpChj acKVqXh0qdLREPab7iTzLl/SPlO5pwPqeJ1CK1eDZn15buFzUT0fWAS2yCx0FnvnG/hH Jf7mV/3V9kdXtZhFkXgWMef6ZmOwhmiz2ra2TSEezcE/zkFlwAeOS/HWq8cfstKH5FWp JaogZPpt8fy5iSW0CZiPfZl2WucmQ0yLUG9U4FzB6wEoXcnB1wzmop9cRBsg2ZmqNZjz fYR35BfwB2nVoLFmMNOXlOcRc/Pk8l2kKhTLkttQyHp9d57r9ovbaKfiLLp3UzzLlmMe UQVg== X-Received: by 10.194.120.134 with SMTP id lc6mr72298114wjb.130.1451381632149; Tue, 29 Dec 2015 01:33:52 -0800 (PST) Received: from planb.netng.org (ip-89-176-92-35.net.upcbroadband.cz. [89.176.92.35]) by smtp.gmail.com with ESMTPSA id pn6sm60317143wjb.15.2015.12.29.01.33.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Dec 2015 01:33:50 -0800 (PST) Date: Tue, 29 Dec 2015 10:33:48 +0100 From: Vladimir Botka To: freebsd-wireless@FreeBSD.org Cc: freebsd-arm@freebsd.org, freebsd-current@FreeBSD.org Subject: Re: D-link wireless not detected Message-ID: <20151229103348.29c9469c@planb.netng.org> In-Reply-To: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> References: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> Organization: na X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/DIbs5Y2xeDqwY7/bk3y2DOC"; protocol="application/pgp-signature" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 09:33:54 -0000 --Sig_/DIbs5Y2xeDqwY7/bk3y2DOC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Danny, On Tue, 29 Dec 2015 11:16:27 +0200 Daniel Braniss wrote: > Hi All, > I have a working tp-link usb (realtek), but can=E2=80=99t get a d-link(al= so realtek) to work. > usbconfig: > ugen0.4: at usbus0, cfg=3D0 md=3DH= OST spd=3DHIGH (480Mbps) pwr=3DON (500mA) > This is on a raspberry pi running a resent current. > cheers & season greetings, > danny I've added freebsd-wireless list. My 2 cents. It might be helpful to see more details about the adapters. For example: # usbconfig -u 0 -a 7 dump_device_desc ugen0.7: <802.11 n WLAN Ralink> at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (450mA) bLength =3D 0x0012=20 bDescriptorType =3D 0x0001=20 bcdUSB =3D 0x0200=20 bDeviceClass =3D 0x0000 bDeviceSubClass =3D 0x0000=20 bDeviceProtocol =3D 0x0000=20 bMaxPacketSize0 =3D 0x0040=20 idVendor =3D 0x148f=20 idProduct =3D 0x5370=20 bcdDevice =3D 0x0101=20 iManufacturer =3D 0x0001 iProduct =3D 0x0002 <802.11 n WLAN> iSerialNumber =3D 0x0003 <1.0> bNumConfigurations =3D 0x0001 Cheers, -vlado --Sig_/DIbs5Y2xeDqwY7/bk3y2DOC Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWglN9AAoJEJDRmRKO1E8BH7wH/1AOUWiO0SHr5UhcXAdz1v19 IWqdpKzPcKvdBaL78wQNKHj/jPBWQtBNw4soSd9dSQ7+p2ujYrdI8T365ntAnDwi Xfw9xPaQlRmy8GZ2086ORv7DzggKssRdOW7mHMhxZDv0FDoSieoyszQ4ZsgKAnIk vQrJZzmLqqwlRh24Hb2WE9PkZQ1eRc8k8sYA6cyU6Bfqru0niJyz/03qjYoIjceK kHLmesIBly9jep47ldfHfMV9j9+fHEqIC+w55tgZOOHd2RpgW5mOumv4jJ3pTy8W 9rICqxLVP0DlgvKZ8hVk2e7GwryS5rKYCB9e1x/FPSqpMS6Gq5+3LH5VNMLCar4= =OICa -----END PGP SIGNATURE----- --Sig_/DIbs5Y2xeDqwY7/bk3y2DOC-- From owner-freebsd-arm@freebsd.org Tue Dec 29 09:43:05 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9805A54E7C; Tue, 29 Dec 2015 09:43:05 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 75E76103C; Tue, 29 Dec 2015 09:43:02 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1aDqnz-000PiY-Vx; Tue, 29 Dec 2015 11:43:00 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: D-link wireless not detected From: Daniel Braniss In-Reply-To: <20151229103348.29c9469c@planb.netng.org> Date: Tue, 29 Dec 2015 11:42:59 +0200 Cc: freebsd-wireless@FreeBSD.org, freebsd-arm@freebsd.org, freebsd-current@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> References: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> <20151229103348.29c9469c@planb.netng.org> To: Vladimir Botka X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 09:43:05 -0000 > On 29 Dec 2015, at 11:33, Vladimir Botka wrote: >=20 > Hi Danny, >=20 > On Tue, 29 Dec 2015 11:16:27 +0200 > Daniel Braniss wrote: >> Hi All, >> I have a working tp-link usb (realtek), but can=E2=80=99t get a = d-link(also realtek) to work. >> usbconfig: >> ugen0.4: at usbus0, cfg=3D0 = md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (500mA) >> This is on a raspberry pi running a resent current. >> cheers & season greetings, >> danny >=20 > I've added freebsd-wireless list. >=20 > My 2 cents. It might be helpful to see more details about the = adapters. > For example: >=20 > # usbconfig -u 0 -a 7 dump_device_desc > ugen0.7: <802.11 n WLAN Ralink> at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH > (480Mbps) pwr=3DON (450mA) > bLength =3D 0x0012=20 > bDescriptorType =3D 0x0001=20 > bcdUSB =3D 0x0200=20 > bDeviceClass =3D 0x0000 > bDeviceSubClass =3D 0x0000=20 > bDeviceProtocol =3D 0x0000=20 > bMaxPacketSize0 =3D 0x0040=20 > idVendor =3D 0x148f=20 > idProduct =3D 0x5370=20 > bcdDevice =3D 0x0101=20 > iManufacturer =3D 0x0001 > iProduct =3D 0x0002 <802.11 n WLAN> > iSerialNumber =3D 0x0003 <1.0> > bNumConfigurations =3D 0x0001 so here it is: root@:~ # usbconfig -u 0 -a 4 dump_device_desc ugen0.4: at usbus0, cfg=3D0 = md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (500mA) bLength =3D 0x0012=20 bDescriptorType =3D 0x0001=20 bcdUSB =3D 0x0210=20 bDeviceClass =3D 0x0000 bDeviceSubClass =3D 0x0000=20 bDeviceProtocol =3D 0x0000=20 bMaxPacketSize0 =3D 0x0040=20 idVendor =3D 0x2001=20 idProduct =3D 0x3319=20 bcdDevice =3D 0x0200=20 iManufacturer =3D 0x0001 iProduct =3D 0x0002 iSerialNumber =3D 0x0003 <00e04c000001> bNumConfigurations =3D 0x0001=20 thanks, danny From owner-freebsd-arm@freebsd.org Tue Dec 29 09:51:12 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8A16A550FE; Tue, 29 Dec 2015 09:51:12 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8513F1500; Tue, 29 Dec 2015 09:51:12 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.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 326D11FE024; Tue, 29 Dec 2015 10:51:10 +0100 (CET) Subject: Re: D-link wireless not detected To: Daniel Braniss , Vladimir Botka References: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> <20151229103348.29c9469c@planb.netng.org> <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> Cc: freebsd-arm@freebsd.org, freebsd-wireless@FreeBSD.org, freebsd-current@FreeBSD.org From: Hans Petter Selasky Message-ID: <5682580B.30107@selasky.org> Date: Tue, 29 Dec 2015 10:53:15 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 09:51:12 -0000 On 12/29/15 10:42, Daniel Braniss wrote: > >> On 29 Dec 2015, at 11:33, Vladimir Botka wrote: >> >> Hi Danny, >> >> On Tue, 29 Dec 2015 11:16:27 +0200 >> Daniel Braniss wrote: >>> Hi All, >>> I have a working tp-link usb (realtek), but can’t get a d-link(also realtek) to work. >>> usbconfig: >>> ugen0.4: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) >>> This is on a raspberry pi running a resent current. >>> cheers & season greetings, >>> danny >> >> I've added freebsd-wireless list. >> >> My 2 cents. It might be helpful to see more details about the adapters. >> For example: >> >> # usbconfig -u 0 -a 7 dump_device_desc >> ugen0.7: <802.11 n WLAN Ralink> at usbus0, cfg=0 md=HOST spd=HIGH >> (480Mbps) pwr=ON (450mA) >> bLength = 0x0012 >> bDescriptorType = 0x0001 >> bcdUSB = 0x0200 >> bDeviceClass = 0x0000 >> bDeviceSubClass = 0x0000 >> bDeviceProtocol = 0x0000 >> bMaxPacketSize0 = 0x0040 >> idVendor = 0x148f >> idProduct = 0x5370 >> bcdDevice = 0x0101 >> iManufacturer = 0x0001 >> iProduct = 0x0002 <802.11 n WLAN> >> iSerialNumber = 0x0003 <1.0> >> bNumConfigurations = 0x0001 > > > so here it is: > root@:~ # usbconfig -u 0 -a 4 dump_device_desc > ugen0.4: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0210 > bDeviceClass = 0x0000 > bDeviceSubClass = 0x0000 > bDeviceProtocol = 0x0000 > bMaxPacketSize0 = 0x0040 > idVendor = 0x2001 > idProduct = 0x3319 > bcdDevice = 0x0200 > iManufacturer = 0x0001 > iProduct = 0x0002 > iSerialNumber = 0x0003 <00e04c000001> > bNumConfigurations = 0x0001 > > thanks, > danny > Did you google the idVendor and idProduct values and see if Linux has a driver already? --HPS From owner-freebsd-arm@freebsd.org Tue Dec 29 10:12:32 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDFC2A55815; Tue, 29 Dec 2015 10:12:32 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 87720106B; Tue, 29 Dec 2015 10:12:32 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1aDrGU-0000Go-OB; Tue, 29 Dec 2015 12:12:26 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: D-link wireless not detected From: Daniel Braniss In-Reply-To: <5682580B.30107@selasky.org> Date: Tue, 29 Dec 2015 12:12:26 +0200 Cc: Vladimir Botka , freebsd-arm@freebsd.org, freebsd-wireless@FreeBSD.org, freebsd-current@FreeBSD.org Message-Id: <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> References: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> <20151229103348.29c9469c@planb.netng.org> <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> <5682580B.30107@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.2104) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 10:12:32 -0000 > On 29 Dec 2015, at 11:53, Hans Petter Selasky wrote: >=20 > On 12/29/15 10:42, Daniel Braniss wrote: >>=20 >>> On 29 Dec 2015, at 11:33, Vladimir Botka wrote: >>>=20 >>> Hi Danny, >>>=20 >>> On Tue, 29 Dec 2015 11:16:27 +0200 >>> Daniel Braniss wrote: >>>> Hi All, >>>> I have a working tp-link usb (realtek), but can=E2=80=99t get a = d-link(also realtek) to work. >>>> usbconfig: >>>> ugen0.4: at usbus0, cfg=3D0 = md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (500mA) >>>> This is on a raspberry pi running a resent current. >>>> cheers & season greetings, >>>> danny >>>=20 >>> I've added freebsd-wireless list. >>>=20 >>> My 2 cents. It might be helpful to see more details about the = adapters. >>> For example: >>>=20 >>> # usbconfig -u 0 -a 7 dump_device_desc >>> ugen0.7: <802.11 n WLAN Ralink> at usbus0, cfg=3D0 md=3DHOST = spd=3DHIGH >>> (480Mbps) pwr=3DON (450mA) >>> bLength =3D 0x0012 >>> bDescriptorType =3D 0x0001 >>> bcdUSB =3D 0x0200 >>> bDeviceClass =3D 0x0000 >>> bDeviceSubClass =3D 0x0000 >>> bDeviceProtocol =3D 0x0000 >>> bMaxPacketSize0 =3D 0x0040 >>> idVendor =3D 0x148f >>> idProduct =3D 0x5370 >>> bcdDevice =3D 0x0101 >>> iManufacturer =3D 0x0001 >>> iProduct =3D 0x0002 <802.11 n WLAN> >>> iSerialNumber =3D 0x0003 <1.0> >>> bNumConfigurations =3D 0x0001 >>=20 >>=20 >> so here it is: >> root@:~ # usbconfig -u 0 -a 4 dump_device_desc >> ugen0.4: at usbus0, cfg=3D0 = md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (500mA) >>=20 >> bLength =3D 0x0012 >> bDescriptorType =3D 0x0001 >> bcdUSB =3D 0x0210 >> bDeviceClass =3D 0x0000 >> bDeviceSubClass =3D 0x0000 >> bDeviceProtocol =3D 0x0000 >> bMaxPacketSize0 =3D 0x0040 >> idVendor =3D 0x2001 >> idProduct =3D 0x3319 >> bcdDevice =3D 0x0200 >> iManufacturer =3D 0x0001 >> iProduct =3D 0x0002 >> iSerialNumber =3D 0x0003 <00e04c000001> >> bNumConfigurations =3D 0x0001 >>=20 >> thanks, >> danny >>=20 >=20 > Did you google the idVendor and idProduct values and see if Linux has = a driver already? >=20 > =E2=80=94HPS >=20 = https://github.com/Mange/rtl8192eu-linux-driver/blob/master/os_dep/linux/u= sb_intf.c = and look at line 216 danny From owner-freebsd-arm@freebsd.org Tue Dec 29 10:18:42 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4997BA559CC; Tue, 29 Dec 2015 10:18:42 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 1230712BD; Tue, 29 Dec 2015 10:18:41 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.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 D7EAE1FE024; Tue, 29 Dec 2015 11:18:31 +0100 (CET) Subject: Re: D-link wireless not detected To: Daniel Braniss References: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> <20151229103348.29c9469c@planb.netng.org> <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> <5682580B.30107@selasky.org> <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> Cc: Vladimir Botka , freebsd-arm@freebsd.org, freebsd-wireless@FreeBSD.org, freebsd-current@FreeBSD.org From: Hans Petter Selasky Message-ID: <56825E74.3050609@selasky.org> Date: Tue, 29 Dec 2015 11:20:36 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 10:18:42 -0000 On 12/29/15 11:12, Daniel Braniss wrote: > > https://github.com/Mange/rtl8192eu-linux-driver/blob/master/os_dep/linux/usb_intf.c > and look at line 216 > > danny Hi, You should be able to get this device working by adding a device entry to: src/sys/dev/usb/wlan/if_urtwn.c Can you make a patch and PR for this, and I'll submit upstream. I recommend you test using an 11-current kernel. --HPS From owner-freebsd-arm@freebsd.org Tue Dec 29 10:28:34 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B065DA55E43 for ; Tue, 29 Dec 2015 10:28:34 +0000 (UTC) (envelope-from crees@physics.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 953421B7E for ; Tue, 29 Dec 2015 10:28:34 +0000 (UTC) (envelope-from crees@physics.org) Received: by mailman.ysv.freebsd.org (Postfix) id 924CFA55E42; Tue, 29 Dec 2015 10:28:34 +0000 (UTC) Delivered-To: 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 782C4A55E41 for ; Tue, 29 Dec 2015 10:28:34 +0000 (UTC) (envelope-from crees@physics.org) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by mx1.freebsd.org (Postfix) with ESMTP id 1B8561B7D for ; Tue, 29 Dec 2015 10:28:33 +0000 (UTC) (envelope-from crees@physics.org) X-Trace: 259553449/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ON_NET_AUTH_ACCEPTED/Talk_Talk_Customer/2.102.6.73/-4.0/crees@physics.org X-SBRS: -4.0 X-RemoteIP: 2.102.6.73 X-IP-MAIL-FROM: crees@physics.org X-SMTP-AUTH: bayofrum@uwclub.net X-MUA: Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AiBwDOX4JWPEkGZgJeFhIBAoMPUolGtl0ihW0CgR1NAQEBAQEBBwEBAQFBP4Q0AQEBAwE4HiIBBQsLDgoJFg8JAwIBAgEnChQGDQEHAogjDAEJvRcBAQEBAQUBAQEBAQEBARcEhlaEM0yJPAEElwaPLYc9DiOFMYpHg3OEbj6FOgEBAQ X-IPAS-Result: A2AiBwDOX4JWPEkGZgJeFhIBAoMPUolGtl0ihW0CgR1NAQEBAQEBBwEBAQFBP4Q0AQEBAwE4HiIBBQsLDgoJFg8JAwIBAgEnChQGDQEHAogjDAEJvRcBAQEBAQUBAQEBAQEBARcEhlaEM0yJPAEElwaPLYc9DiOFMYpHg3OEbj6FOgEBAQ X-IronPort-AV: E=Sophos;i="5.20,494,1444690800"; d="scan'208";a="259553449" X-IP-Direction: OUT Received: from host-2-102-6-73.as13285.net (HELO pegasus.bayofrum.net) ([2.102.6.73]) by smtp.pipex.tiscali.co.uk with ESMTP; 29 Dec 2015 10:28:31 +0000 Received: from [192.168.1.181] (HESTIA.bayofrum.net [192.168.1.181]) by pegasus.bayofrum.net (Postfix) with ESMTPSA id 143E8198D3; Tue, 29 Dec 2015 10:27:13 +0000 (GMT) Message-ID: <56825C37.9070805@physics.org> Date: Tue, 29 Dec 2015 10:11:03 +0000 From: Chris Rees User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29 MIME-Version: 1.0 To: Konstantin Belousov CC: arm@FreeBSD.org Subject: Re: Cross building ports amd64/armv6 References: <5681AD3F.6000202@physics.org> <20151228222531.GT3625@kib.kiev.ua> In-Reply-To: <20151228222531.GT3625@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-bayofrum-MailScanner-Information: Please contact the ISP for more information X-bayofrum-MailScanner-ID: 143E8198D3.ADA3C X-bayofrum-MailScanner: Found to be clean X-bayofrum-MailScanner-From: crees@physics.org X-Spam-Status: No X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 10:28:34 -0000 Konstantin Belousov wrote: > On Mon, Dec 28, 2015 at 09:44:31PM +0000, Chris Rees wrote: >> The issue I have is with the odd port that tries to install(1) >> empty files, such as lang/python27 and audio/libvorbis [2]. >> >> I can reproduce this by entering the build jail, and *on the wrkdir >> mount* touching a, installing a b. >> >> The wrkdir is created with mdconfig -a -t swap -s 3G by poudriere, >> and it doesn't happen on the zfs partition that the partition >> resides on. I've narrowed it down to this ancient optimisation >> (mmap and write if less than 8M), which is from ~r1000 [3]; if I >> disable this block of code and just use the code below it (read to >> buf, write from buf) the problem disappears. > It took an effort to understand what is your problem. Is it EFAULT > from something in install(1) ? Thanks for the quick reply. Yes, the EFAULT comes from install as far as I can tell. > Does it happen on amd64 system or on arm system ? It happens on the amd64 system, in an armv6 jail. > What are the filesystem types both for the source and destination > files locations for failing install ? This is within the same filesystem- UFS. I've discovered md has nothing to do with it-- UFS on ada0p4 also has the same issue, but only within the jail i.e. only with the armv6 (x)install binary. Doesn't happen with ZFS, even if I make a new zpool and mount it inside the jail. > Also, provide the ktrace -t '+f' / kdump output for the failing > install(1) run. ktrace doesn't work inside the jail of course, so I made this with: % sudo ktrace -t '+f' jexec 278 install wrkdirs/a wrkdirs/c https://www.bayofrum.net/~crees/scratch/pfault Hope that's enough. Chris -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-arm@freebsd.org Tue Dec 29 12:15:06 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A62A0A54B7A for ; Tue, 29 Dec 2015 12:15:06 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 4FEE11634; Tue, 29 Dec 2015 12:15:05 +0000 (UTC) (envelope-from brett@lariat.net) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id VAA02387; Sun, 27 Dec 2015 21:50:15 -0700 (MST) Message-Id: <201512280450.VAA02387@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 27 Dec 2015 21:50:14 -0700 To: Ian Lepore , freebsd-arm@freebsd.org From: Brett Glass Subject: Re: Getting started with freebsd-arm on Cubox-i2 In-Reply-To: <1451272216.1369.25.camel@freebsd.org> References: <201512272145.OAA28860@mail.lariat.net> <1451264046.1369.21.camel@freebsd.org> <201512280230.TAA01501@mail.lariat.net> <1451272216.1369.25.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 12:15:06 -0000 At 08:10 PM 12/27/2015, Ian Lepore wrote: >Since there are no video drivers in the image you're running, there's >no memory wasted on a framebuffer. The remaining memory is the kernel >itself and page tables and other things that aren't accounted for by >the vm system, which is where the numbers in top come from. Great! My next question: How to get more storage. When I flashed onto an 8 GB card, booted, and then brought in the package manager, I filled the card. If I put in a 16 GB card, will FFS automatically be expanded to fill the card? Or will I have to do that manually? --Brett From owner-freebsd-arm@freebsd.org Tue Dec 29 12:26:28 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 439A1A530BC; Tue, 29 Dec 2015 12:26:28 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F24A01B06; Tue, 29 Dec 2015 12:26:27 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1aDtM4-0002Kx-Vx; Tue, 29 Dec 2015 14:26:21 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: D-link wireless not detected From: Daniel Braniss In-Reply-To: <56825E74.3050609@selasky.org> Date: Tue, 29 Dec 2015 14:26:20 +0200 Cc: Vladimir Botka , freebsd-arm@freebsd.org, freebsd-wireless@FreeBSD.org, freebsd-current@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <1EC3E6CB-5031-46F3-A3AD-329DB1FDC882@cs.huji.ac.il> References: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> <20151229103348.29c9469c@planb.netng.org> <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> <5682580B.30107@selasky.org> <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> <56825E74.3050609@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 12:26:28 -0000 > On 29 Dec 2015, at 12:20, Hans Petter Selasky wrote: >=20 > On 12/29/15 11:12, Daniel Braniss wrote: >>=20 >> = https://github.com/Mange/rtl8192eu-linux-driver/blob/master/os_dep/linux/u= sb_intf.c = >> and look at line 216 >>=20 >> danny >=20 > Hi, >=20 > You should be able to get this device working by adding a device entry = to: >=20 > src/sys/dev/usb/wlan/if_urtwn.c >=20 > Can you make a patch and PR for this, and I'll submit upstream. I = recommend you test using an 11-current kernel. >=20 > --HPS clearly, I=E2=80=99m missing something, because it=E2=80=99s not working = :-( the only visible change is now ugen0.4: <802.11n WLAN Adapter RealtekWireless N Nano USB A> at usbus0, = cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (500mA) before it was ugen0.4: at usbus0, cfg=3D0 = md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (500mA) rnd> svn diff Index: usbdevs =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 --- usbdevs (revision 291745) +++ usbdevs (working copy) @@ -1657,6 +1657,7 @@ product DLINK2 RTL8192SU_1 0x3300 RTL8192SU product DLINK2 RTL8192SU_2 0x3302 RTL8192SU product DLINK2 DWA131A1 0x3303 DWA-131 A1 +product DLINK DWA131 0x3319 DWA-131 product DLINK2 DWA160A2 0x3a09 DWA-160 A2 product DLINK2 DWA120 0x3a0c DWA-120 product DLINK2 DWA120_NF 0x3a0d DWA-120 (no firmware) Index: wlan/if_urtwn.c =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 --- wlan/if_urtwn.c (revision 291745) +++ wlan/if_urtwn.c (working copy) @@ -116,6 +116,7 @@ URTWN_DEV(DLINK, RTL8192CU_2), URTWN_DEV(DLINK, RTL8192CU_3), URTWN_DEV(DLINK, DWA131B), + URTWN_DEV(DLINK, DWA131), // danny URTWN_DEV(EDIMAX, EW7811UN), URTWN_DEV(EDIMAX, RTL8192CU), URTWN_DEV(FEIXUN, RTL8188CU), From owner-freebsd-arm@freebsd.org Tue Dec 29 12:29:02 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80577A531F9; Tue, 29 Dec 2015 12:29:02 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4988B1D2F; Tue, 29 Dec 2015 12:29:02 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.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 646871FE024; Tue, 29 Dec 2015 13:28:59 +0100 (CET) Subject: Re: D-link wireless not detected To: Daniel Braniss References: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> <20151229103348.29c9469c@planb.netng.org> <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> <5682580B.30107@selasky.org> <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> <56825E74.3050609@selasky.org> <1EC3E6CB-5031-46F3-A3AD-329DB1FDC882@cs.huji.ac.il> Cc: Vladimir Botka , freebsd-arm@freebsd.org, freebsd-wireless@FreeBSD.org, freebsd-current@FreeBSD.org From: Hans Petter Selasky Message-ID: <56827D08.2070602@selasky.org> Date: Tue, 29 Dec 2015 13:31:04 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1EC3E6CB-5031-46F3-A3AD-329DB1FDC882@cs.huji.ac.il> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 12:29:02 -0000 On 12/29/15 13:26, Daniel Braniss wrote: > >> On 29 Dec 2015, at 12:20, Hans Petter Selasky wrote: >> >> On 12/29/15 11:12, Daniel Braniss wrote: >>> >>> https://github.com/Mange/rtl8192eu-linux-driver/blob/master/os_dep/linux/usb_intf.c >>> and look at line 216 >>> >>> danny >> >> Hi, >> >> You should be able to get this device working by adding a device entry to: >> >> src/sys/dev/usb/wlan/if_urtwn.c >> >> Can you make a patch and PR for this, and I'll submit upstream. I recommend you test using an 11-current kernel. >> >> --HPS > > clearly, I’m missing something, because it’s not working :-( > the only visible change is now > ugen0.4: <802.11n WLAN Adapter RealtekWireless N Nano USB A> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) > before it was > ugen0.4: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) > > rnd> svn diff > Index: usbdevs > =================================================================== > --- usbdevs (revision 291745) > +++ usbdevs (working copy) > @@ -1657,6 +1657,7 @@ > product DLINK2 RTL8192SU_1 0x3300 RTL8192SU > product DLINK2 RTL8192SU_2 0x3302 RTL8192SU > product DLINK2 DWA131A1 0x3303 DWA-131 A1 > +product DLINK DWA131 0x3319 DWA-131 > product DLINK2 DWA160A2 0x3a09 DWA-160 A2 > product DLINK2 DWA120 0x3a0c DWA-120 > product DLINK2 DWA120_NF 0x3a0d DWA-120 (no firmware) > Index: wlan/if_urtwn.c > =================================================================== > --- wlan/if_urtwn.c (revision 291745) > +++ wlan/if_urtwn.c (working copy) > @@ -116,6 +116,7 @@ > URTWN_DEV(DLINK, RTL8192CU_2), > URTWN_DEV(DLINK, RTL8192CU_3), > URTWN_DEV(DLINK, DWA131B), > + URTWN_DEV(DLINK, DWA131), // danny > URTWN_DEV(EDIMAX, EW7811UN), > URTWN_DEV(EDIMAX, RTL8192CU), > URTWN_DEV(FEIXUN, RTL8188CU), > Hi, You should use vendor RALINK (according to your usbconfig dump) vendor RALINK 0x148f Ralink Technology --HPS From owner-freebsd-arm@freebsd.org Tue Dec 29 12:36:44 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3652A5380C; Tue, 29 Dec 2015 12:36:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 50FC71566; Tue, 29 Dec 2015 12:36:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1aDtW3-0002Rf-5u; Tue, 29 Dec 2015 14:36:39 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: D-link wireless not detected From: Daniel Braniss In-Reply-To: <56827D08.2070602@selasky.org> Date: Tue, 29 Dec 2015 14:36:38 +0200 Cc: Vladimir Botka , freebsd-arm@freebsd.org, freebsd-wireless@FreeBSD.org, freebsd-current@FreeBSD.org Message-Id: References: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> <20151229103348.29c9469c@planb.netng.org> <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> <5682580B.30107@selasky.org> <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> <56825E74.3050609@selasky.org> <1EC3E6CB-5031-46F3-A3AD-329DB1FDC882@cs.huji.ac.il> <56827D08.2070602@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.2104) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 12:36:44 -0000 > On 29 Dec 2015, at 14:31, Hans Petter Selasky wrote: >=20 > On 12/29/15 13:26, Daniel Braniss wrote: >>=20 >>> On 29 Dec 2015, at 12:20, Hans Petter Selasky = wrote: >>>=20 >>> On 12/29/15 11:12, Daniel Braniss wrote: >>>>=20 >>>> = https://github.com/Mange/rtl8192eu-linux-driver/blob/master/os_dep/linux/u= sb_intf.c = >>>> and look at line 216 >>>>=20 >>>> danny >>>=20 >>> Hi, >>>=20 >>> You should be able to get this device working by adding a device = entry to: >>>=20 >>> src/sys/dev/usb/wlan/if_urtwn.c >>>=20 >>> Can you make a patch and PR for this, and I'll submit upstream. I = recommend you test using an 11-current kernel. >>>=20 >>> --HPS >>=20 >> clearly, I=E2=80=99m missing something, because it=E2=80=99s not = working :-( >> the only visible change is now >> ugen0.4: <802.11n WLAN Adapter RealtekWireless N Nano USB A> at = usbus0, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (500mA) >> before it was >> ugen0.4: at usbus0, cfg=3D0 = md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (500mA) >>=20 >> rnd> svn diff >> Index: usbdevs >> =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 >> --- usbdevs (revision 291745) >> +++ usbdevs (working copy) >> @@ -1657,6 +1657,7 @@ >> product DLINK2 RTL8192SU_1 0x3300 RTL8192SU >> product DLINK2 RTL8192SU_2 0x3302 RTL8192SU >> product DLINK2 DWA131A1 0x3303 DWA-131 A1 >> +product DLINK DWA131 0x3319 DWA-131 >> product DLINK2 DWA160A2 0x3a09 DWA-160 A2 >> product DLINK2 DWA120 0x3a0c DWA-120 >> product DLINK2 DWA120_NF 0x3a0d DWA-120 (no firmware) >> Index: wlan/if_urtwn.c >> =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 >> --- wlan/if_urtwn.c (revision 291745) >> +++ wlan/if_urtwn.c (working copy) >> @@ -116,6 +116,7 @@ >> URTWN_DEV(DLINK, RTL8192CU_2), >> URTWN_DEV(DLINK, RTL8192CU_3), >> URTWN_DEV(DLINK, DWA131B), >> + URTWN_DEV(DLINK, DWA131), // danny >> URTWN_DEV(EDIMAX, EW7811UN), >> URTWN_DEV(EDIMAX, RTL8192CU), >> URTWN_DEV(FEIXUN, RTL8188CU), >>=20 >=20 > Hi, >=20 > You should use vendor RALINK (according to your usbconfig dump) >=20 > vendor RALINK 0x148f Ralink Technology you are confusing Vladimir=E2=80=99s with mine. here is mine again: ugen0.4: at usbus0, cfg=3D0 = md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (500mA) bLength =3D 0x0012=20 bDescriptorType =3D 0x0001=20 bcdUSB =3D 0x0210=20 bDeviceClass =3D 0x0000 bDeviceSubClass =3D 0x0000=20 bDeviceProtocol =3D 0x0000=20 bMaxPacketSize0 =3D 0x0040=20 idVendor =3D 0x2001 <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D D-LINK idProduct =3D 0x3319=20 bcdDevice =3D 0x0200=20 iManufacturer =3D 0x0001 iProduct =3D 0x0002 iSerialNumber =3D 0x0003 <00e04c000001> bNumConfigurations =3D 0x0001=20 danny From owner-freebsd-arm@freebsd.org Tue Dec 29 12:42:09 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C28DA53B54; Tue, 29 Dec 2015 12:42:09 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 13BBB1B92; Tue, 29 Dec 2015 12:42:08 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.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 B99661FE024; Tue, 29 Dec 2015 13:42:06 +0100 (CET) Subject: Re: D-link wireless not detected To: Daniel Braniss References: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> <20151229103348.29c9469c@planb.netng.org> <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> <5682580B.30107@selasky.org> <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> <56825E74.3050609@selasky.org> <1EC3E6CB-5031-46F3-A3AD-329DB1FDC882@cs.huji.ac.il> <56827D08.2070602@selasky.org> Cc: Vladimir Botka , freebsd-arm@freebsd.org, freebsd-wireless@FreeBSD.org, freebsd-current@FreeBSD.org From: Hans Petter Selasky Message-ID: <5682801B.6020404@selasky.org> Date: Tue, 29 Dec 2015 13:44:11 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 12:42:09 -0000 On 12/29/15 13:36, Daniel Braniss wrote: > Until /etc/devd/usb.conf is regenerated, you'll need to manually load the kernel module for urtwn. Did you do that? --HPS From owner-freebsd-arm@freebsd.org Tue Dec 29 13:00:52 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7950EA54183; Tue, 29 Dec 2015 13:00:52 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 328501334; Tue, 29 Dec 2015 13:00:51 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1aDttO-0003JH-AZ; Tue, 29 Dec 2015 15:00:46 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: D-link wireless not detected From: Daniel Braniss In-Reply-To: <5682801B.6020404@selasky.org> Date: Tue, 29 Dec 2015 15:00:45 +0200 Cc: Vladimir Botka , freebsd-arm@freebsd.org, freebsd-wireless@FreeBSD.org, freebsd-current@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> <20151229103348.29c9469c@planb.netng.org> <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> <5682580B.30107@selasky.org> <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> <56825E74.3050609@selasky.org> <1EC3E6CB-5031-46F3-A3AD-329DB1FDC882@cs.huji.ac.il> <56827D08.2070602@selasky.org> <5682801B.6020404@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 13:00:52 -0000 > On 29 Dec 2015, at 14:44, Hans Petter Selasky wrote: >=20 > On 12/29/15 13:36, Daniel Braniss wrote: >>=20 >=20 > Until /etc/devd/usb.conf is regenerated, you'll need to manually load = the kernel module for urtwn. Did you do that? >=20 > --HPS >=20 ok, set if_urtwn_load=3Dyes and now I get: ugen0.4: at usbus0 urtwn0: on usbus0 urtwn0: could not allocate USB transfers, err=3DUSB_ERR_NO_PIPE Fatal kernel mode data abort: 'Translation Fault (L1)' on write trapframe: 0xda29fb88 FSR=3D00000805, FAR=3D00000000, spsr=3D60000013 r0 =3D00000000, r1 =3D00000000, r2 =3Dc0a72cb0, r3 =3D00000165 r4 =3Dc2cd0000, r5 =3Dc0a86650, r6 =3Dc2cd1a80, r7 =3D00000000 r8 =3Dc2cd1dd8, r9 =3Dc2cd1a20, r10=3Dc2a85dd0, r11=3Dda29fc20 r12=3D00000000, ssp=3Dda29fc18, slr=3D00000004, pc =3Dc0a3f7cc [ thread pid 13 tid 100045 ] Stopped at ieee80211_ifdetach+0x4c: str r0, [r1] db>=20 btw, as long as you are willing to help, I will keep testing, in other words, i=E2=80=99m ok. thanks, danny From owner-freebsd-arm@freebsd.org Tue Dec 29 13:22:45 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B0D0A54992 for ; Tue, 29 Dec 2015 13:22:45 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CA271EA3 for ; Tue, 29 Dec 2015 13:22:44 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id tBTDMKhg043411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Dec 2015 14:22:27 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id tBTDMEDd019013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Dec 2015 14:22:14 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id tBTDMEIY050340; Tue, 29 Dec 2015 14:22:14 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id tBTDMDCV050339; Tue, 29 Dec 2015 14:22:13 +0100 (CET) (envelope-from ticso) Date: Tue, 29 Dec 2015 14:22:13 +0100 From: Bernd Walter To: Matthieu Volat Cc: ticso@cicely.de, freebsd-arm@freebsd.org Subject: Re: Raspberry Pi and WaveShare SpotPear LCD screens Message-ID: <20151229132213.GB48795@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <36285EFC-0739-4A93-B22D-C22B7BDEE16D@alkumuna.eu> <20151228135554.GA45251@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 13:22:45 -0000 On Mon, Dec 28, 2015 at 04:40:59PM +0100, Matthieu Volat wrote: > > > Le 28 déc. 2015 à 14:55, Bernd Walter a écrit : > > > [...] > > > > Basicly they run with fixed configuration HDMI dummy output and then > > copy the framebuffer over SPI to the display, which has it's own > > displaymemory. > > The board has some shift registers, so I'm guessing that the panel > > itself uses a memory bus. > > At least one GPIOs is used for backlight and I think there is an enable. > > The touch controller is connected to I2C and needs it's own driver too. > > Havn't worked out the details. > > Easiest for you would be to use one of their bigger HDMI displays. > > They have 5" and 7" and recently also 10.x". > > Be aware that they have two 5" - one is connected to the GPIO header > > for Power and I²C to run the touch controller. > > The other one uses USB cables and an STM32 controller to run the touch > > controller as an USB device - not sure if it is a standard device, > > since I'd tested it with a Linux desktop and it didn't run out of the box. > > I havn't run any FreeBSD with display yet. > > > > Thanks, that's a very good summary. So if I understand well, we'd need to add a whole new class of framebuffer. That would be a good exercise, but I fear not having enough time/knowledge to do so... not soon at least. Or just a driver that copies over as done withLinux, which theoretically could also be done in userland. The advantage for copying vs. a new framebuffer is that the GPU features can be used for creating the image, but IIRC we don't support the GPU anyway. I have a complete set of their modules, including the HDMI with the exception of the 10.x" one, which wasn't available when I'd ordered them. But in my case I was under time Pressure, so I had to use Linux. > Thank you very much, I'll try to read a bit more about the fb devices in /usr/src/arm/bcm2835, as well as look a bit at the fbtft module in Linux staging area. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Tue Dec 29 13:28:48 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8F9AA54BCF for ; Tue, 29 Dec 2015 13:28:48 +0000 (UTC) (envelope-from sig6247@openmailbox.org) Received: from smtp16.openmailbox.org (smtp16.openmailbox.org [62.4.1.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B2581FEA for ; Tue, 29 Dec 2015 13:28:48 +0000 (UTC) (envelope-from sig6247@openmailbox.org) Received: by mail2.openmailbox.org (Postfix, from userid 1002) id AB6447C2D5E; Tue, 29 Dec 2015 12:01:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1451386877; bh=C/7SMLZkCtg0LJowwpI5ZIW1K6JwmMmb5WzlHMYVN18=; h=Date:From:To:Subject:From; b=nMiPGeTB3ygOiFll5qsrodzvW7sPGSLpQv9LvN6zsLnU+tQHjzQQp3Lphx/3Ue0nY /ejUlKSjtG0NXjjVyF0EowjaoLXYXhpjzGiGl+dX+GV+okHTBiw6YzDymj4Ie/wtKJ 17kdbtPa8bBwXYYQ3YSEggXvdvEcOVYVJWtk0srI= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on openmailbox-b1 X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MISSING_MID,NO_RECEIVED,NO_RELAYS autolearn=no autolearn_force=no version=3.4.0 Date: Tue, 29 Dec 2015 11:00:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1451386877; bh=C/7SMLZkCtg0LJowwpI5ZIW1K6JwmMmb5WzlHMYVN18=; h=Date:From:To:Subject:From; b=nMiPGeTB3ygOiFll5qsrodzvW7sPGSLpQv9LvN6zsLnU+tQHjzQQp3Lphx/3Ue0nY /ejUlKSjtG0NXjjVyF0EowjaoLXYXhpjzGiGl+dX+GV+okHTBiw6YzDymj4Ie/wtKJ 17kdbtPa8bBwXYYQ3YSEggXvdvEcOVYVJWtk0srI= From: sig6247 To: freebsd-arm@freebsd.org Subject: emac0 not working on BananaPi M1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20151229110117.AB6447C2D5E@mail2.openmailbox.org> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 13:28:48 -0000 Hi, I'm running 11.0-CURRENT r291838 on a BananaPi M1, emac0 never worked for me, so I have to use a wireless adaper all the time. Is it a known problem or it just doesn't work on my board ... Thanks, From owner-freebsd-arm@freebsd.org Tue Dec 29 13:30:11 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC5B7A54CD9 for ; Tue, 29 Dec 2015 13:30:10 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BBD591083 for ; Tue, 29 Dec 2015 13:30:10 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-ob0-x231.google.com with SMTP id 18so252252920obc.2 for ; Tue, 29 Dec 2015 05:30:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Moyz+sxobOENcupAcFkh2PWL26msogxjrG/IekeooVg=; b=IsDqV/DGOdDXP9tE5XfnrCF+hPIQuvaz9DBm4onmH6EX1SSuDEWnspJu2apiojhEYX jeVu8StIilwxSTzvDVP7YQHtWpBvZeibRnCUQYLEImmncGfi8BZKnHQh2xH57YB8FNCB LtoAm2JqH5XCjSI4zLEq0oPPe6/o1HTjlQ820zYa8Dz3R9uTjHNR1xREjDgffHHRXqHf VvAj2IjiKO2WTyqX6S7wN3MmEhp6Zg3kNAcKnsDKl92/32Cyw4KMN8rG5M7UfS1AZftu aBQm4iGpnQqyuVC0k6FMkvYKTwlbPE96gtrOiwRvRNZYRhlx7vkVtBhLlZigls3j+xb9 wuiA== MIME-Version: 1.0 X-Received: by 10.60.74.100 with SMTP id s4mr37677909oev.36.1451395809866; Tue, 29 Dec 2015 05:30:09 -0800 (PST) Received: by 10.182.169.34 with HTTP; Tue, 29 Dec 2015 05:30:09 -0800 (PST) In-Reply-To: <20151229110117.AB6447C2D5E@mail2.openmailbox.org> References: <20151229110117.AB6447C2D5E@mail2.openmailbox.org> Date: Tue, 29 Dec 2015 21:30:09 +0800 Message-ID: Subject: Re: emac0 not working on BananaPi M1 From: Ganbold Tsagaankhuu To: sig6247 Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 13:30:11 -0000 On Tue, Dec 29, 2015 at 7:00 PM, sig6247 wrote: > > Hi, > > I'm running 11.0-CURRENT r291838 on a BananaPi M1, emac0 never worked > for me, so I have to use a wireless adaper all the time. > bananapi1 has gmac too, so you should really use if_dwc. > > Is it a known problem or it just doesn't work on my board ... > > Thanks, > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Tue Dec 29 13:58:23 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59EAAA55657; Tue, 29 Dec 2015 13:58:23 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EB7C91E1C; Tue, 29 Dec 2015 13:58:22 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.14.9/8.14.9) with ESMTP id tBTDvHwO016004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Dec 2015 21:57:18 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.14.9/8.14.9/Submit) id tBTDvFb7016003; Tue, 29 Dec 2015 21:57:15 +0800 (CST) (envelope-from kevlo) Date: Tue, 29 Dec 2015 21:57:15 +0800 From: Kevin Lo To: Daniel Braniss Cc: Hans Petter Selasky , freebsd-wireless@FreeBSD.org, freebsd-arm@freebsd.org, freebsd-current@FreeBSD.org Subject: Re: D-link wireless not detected Message-ID: <20151229135715.GA15933@ns.kevlo.org> References: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> <20151229103348.29c9469c@planb.netng.org> <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> <5682580B.30107@selasky.org> <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 13:58:23 -0000 On Tue, Dec 29, 2015 at 12:12:26PM +0200, Daniel Braniss wrote: > > > On 29 Dec 2015, at 11:53, Hans Petter Selasky wrote: > > > > On 12/29/15 10:42, Daniel Braniss wrote: > >> > >>> On 29 Dec 2015, at 11:33, Vladimir Botka wrote: > >>> > >>> Hi Danny, > >>> > >>> On Tue, 29 Dec 2015 11:16:27 +0200 > >>> Daniel Braniss wrote: > >>>> Hi All, > >>>> I have a working tp-link usb (realtek), but can’t get a d-link(also realtek) to work. > >>>> usbconfig: > >>>> ugen0.4: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) > >>>> This is on a raspberry pi running a resent current. > >>>> cheers & season greetings, > >>>> danny > >>> > >>> I've added freebsd-wireless list. > >>> > >>> My 2 cents. It might be helpful to see more details about the adapters. > >>> For example: > >>> > >>> # usbconfig -u 0 -a 7 dump_device_desc > >>> ugen0.7: <802.11 n WLAN Ralink> at usbus0, cfg=0 md=HOST spd=HIGH > >>> (480Mbps) pwr=ON (450mA) > >>> bLength = 0x0012 > >>> bDescriptorType = 0x0001 > >>> bcdUSB = 0x0200 > >>> bDeviceClass = 0x0000 > >>> bDeviceSubClass = 0x0000 > >>> bDeviceProtocol = 0x0000 > >>> bMaxPacketSize0 = 0x0040 > >>> idVendor = 0x148f > >>> idProduct = 0x5370 > >>> bcdDevice = 0x0101 > >>> iManufacturer = 0x0001 > >>> iProduct = 0x0002 <802.11 n WLAN> > >>> iSerialNumber = 0x0003 <1.0> > >>> bNumConfigurations = 0x0001 > >> > >> > >> so here it is: > >> root@:~ # usbconfig -u 0 -a 4 dump_device_desc > >> ugen0.4: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) > >> > >> bLength = 0x0012 > >> bDescriptorType = 0x0001 > >> bcdUSB = 0x0210 > >> bDeviceClass = 0x0000 > >> bDeviceSubClass = 0x0000 > >> bDeviceProtocol = 0x0000 > >> bMaxPacketSize0 = 0x0040 > >> idVendor = 0x2001 > >> idProduct = 0x3319 > >> bcdDevice = 0x0200 > >> iManufacturer = 0x0001 > >> iProduct = 0x0002 > >> iSerialNumber = 0x0003 <00e04c000001> > >> bNumConfigurations = 0x0001 > >> > >> thanks, > >> danny > >> > > > > Did you google the idVendor and idProduct values and see if Linux has a driver already? > > > > —HPS > > > > > https://github.com/Mange/rtl8192eu-linux-driver/blob/master/os_dep/linux/usb_intf.c > and look at line 216 Your device (D-Link DWA-131 rev E1) is rtl8192eu, which is not supported by FreeBSD. > danny Kevin From owner-freebsd-arm@freebsd.org Tue Dec 29 14:00:33 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40A09A55737; Tue, 29 Dec 2015 14:00:33 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 03B941FC4; Tue, 29 Dec 2015 14:00:32 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.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 93E7D1FE024; Tue, 29 Dec 2015 15:00:30 +0100 (CET) Subject: Re: D-link wireless not detected To: Daniel Braniss References: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> <20151229103348.29c9469c@planb.netng.org> <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> <5682580B.30107@selasky.org> <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> <56825E74.3050609@selasky.org> <1EC3E6CB-5031-46F3-A3AD-329DB1FDC882@cs.huji.ac.il> <56827D08.2070602@selasky.org> <5682801B.6020404@selasky.org> Cc: Vladimir Botka , freebsd-arm@freebsd.org, freebsd-wireless@FreeBSD.org, freebsd-current@FreeBSD.org, Andriy Voskoboinyk From: Hans Petter Selasky Message-ID: <5682927B.6020704@selasky.org> Date: Tue, 29 Dec 2015 15:02:35 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 14:00:33 -0000 On 12/29/15 14:00, Daniel Braniss wrote: > >> On 29 Dec 2015, at 14:44, Hans Petter Selasky wrote: >> >> On 12/29/15 13:36, Daniel Braniss wrote: >>> >> >> Until /etc/devd/usb.conf is regenerated, you'll need to manually load the kernel module for urtwn. Did you do that? >> >> --HPS >> > ok, set if_urtwn_load=yes > and now I get: > > ugen0.4: at usbus0 > urtwn0: on usbus0 > urtwn0: could not allocate USB transfers, err=USB_ERR_NO_PIPE > Fatal kernel mode data abort: 'Translation Fault (L1)' on write > trapframe: 0xda29fb88 > FSR=00000805, FAR=00000000, spsr=60000013 > r0 =00000000, r1 =00000000, r2 =c0a72cb0, r3 =00000165 > r4 =c2cd0000, r5 =c0a86650, r6 =c2cd1a80, r7 =00000000 > r8 =c2cd1dd8, r9 =c2cd1a20, r10=c2a85dd0, r11=da29fc20 > r12=00000000, ssp=da29fc18, slr=00000004, pc =c0a3f7cc > > [ thread pid 13 tid 100045 ] > Stopped at ieee80211_ifdetach+0x4c: str r0, [r1] > db> > > btw, as long as you are willing to help, I will keep testing, > in other words, i’m ok. Hi Andriy, Can you fix the crash above and verify this error patch? Andriy: After: usbd_transfer_unsetup(sc->sc_xfer, URTWN_N_TRANSFER); There is no need for: usbd_transfer_drain(sc->sc_xfer[x]); --HPS From owner-freebsd-arm@freebsd.org Tue Dec 29 14:05:01 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCFC9A559A4; Tue, 29 Dec 2015 14:05:01 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 8337114C9; Tue, 29 Dec 2015 14:05:01 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.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 96D5A1FE024; Tue, 29 Dec 2015 15:04:59 +0100 (CET) Subject: Re: D-link wireless not detected To: Daniel Braniss References: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> <20151229103348.29c9469c@planb.netng.org> <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> <5682580B.30107@selasky.org> <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> <56825E74.3050609@selasky.org> <1EC3E6CB-5031-46F3-A3AD-329DB1FDC882@cs.huji.ac.il> <56827D08.2070602@selasky.org> <5682801B.6020404@selasky.org> <5682927B.6020704@selasky.org> Cc: Andriy Voskoboinyk , freebsd-wireless@FreeBSD.org, freebsd-arm@freebsd.org, freebsd-current@FreeBSD.org From: Hans Petter Selasky Message-ID: <56829387.7080508@selasky.org> Date: Tue, 29 Dec 2015 15:07:03 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5682927B.6020704@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 14:05:01 -0000 On 12/29/15 15:02, Hans Petter Selasky wrote: > On 12/29/15 14:00, Daniel Braniss wrote: >> >>> On 29 Dec 2015, at 14:44, Hans Petter Selasky wrote: >>> >>> On 12/29/15 13:36, Daniel Braniss wrote: >>>> >>> >>> Until /etc/devd/usb.conf is regenerated, you'll need to manually load >>> the kernel module for urtwn. Did you do that? >>> >>> --HPS >>> >> ok, set if_urtwn_load=yes >> and now I get: >> >> ugen0.4: at usbus0 >> urtwn0: on usbus0 >> urtwn0: could not allocate USB transfers, err=USB_ERR_NO_PIPE >> Fatal kernel mode data abort: 'Translation Fault (L1)' on write >> trapframe: 0xda29fb88 >> FSR=00000805, FAR=00000000, spsr=60000013 >> r0 =00000000, r1 =00000000, r2 =c0a72cb0, r3 =00000165 >> r4 =c2cd0000, r5 =c0a86650, r6 =c2cd1a80, r7 =00000000 >> r8 =c2cd1dd8, r9 =c2cd1a20, r10=c2a85dd0, r11=da29fc20 >> r12=00000000, ssp=da29fc18, slr=00000004, pc =c0a3f7cc >> >> [ thread pid 13 tid 100045 ] >> Stopped at ieee80211_ifdetach+0x4c: str r0, [r1] >> db> >> >> btw, as long as you are willing to help, I will keep testing, >> in other words, i’m ok. > > Hi Andriy, > > Can you fix the crash above and verify this error patch? > Hi, I see 11-current has a fix. Maybe MFC that to 10-stable? > Andriy: > > After: > usbd_transfer_unsetup(sc->sc_xfer, URTWN_N_TRANSFER); > There is no need for: > usbd_transfer_drain(sc->sc_xfer[x]); --HPS From owner-freebsd-arm@freebsd.org Tue Dec 29 14:09:04 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A24A5A55B1D; Tue, 29 Dec 2015 14:09:04 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 750211810; Tue, 29 Dec 2015 14:09:04 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by mail-pa0-x22d.google.com with SMTP id cy9so124803334pac.0; Tue, 29 Dec 2015 06:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:reply-to:subject:references:to:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=5180giaH4ELEqUUFFr45LJKGFdRYo7ro5LF0KCvNiQo=; b=dpaxFlNMoi/wzIbcEG7KA45V4ij1YrAtu+1YFN7O04Ln3r1wIs6K/nJRe8XzE6DAME EYzTbF+9sy/dzx18ZicBTE1xKpdcx7tj624R8X1o6WoPwpjCgSlVV6qN1pKnYNxSN1oe E87Rtk6nXtjXM4eakC73Lh9+StE73q2abZqCOm8EbtG10T24gP2SWVxqwLVkMTAOpy5i WUF2DkncViVEDUYH/brMEhVMFxbpWnC6y7ZwMKgdFfe4nNuYWO5n/hq77pYYEK34l78P Qy9Tj3o067y6VQlH1Mj08HPmElL748Yg5KsMON2pHqWrXNK8VLhxDtlj9dt4M51HeFC9 4Ztw== X-Received: by 10.66.222.101 with SMTP id ql5mr86597169pac.144.1451398144159; Tue, 29 Dec 2015 06:09:04 -0800 (PST) Received: from ?IPv6:2001:44b8:31ae:7b01:adf9:d5f0:d710:6dae? (2001-44b8-31ae-7b01-adf9-d5f0-d710-6dae.static.ipv6.internode.on.net. [2001:44b8:31ae:7b01:adf9:d5f0:d710:6dae]) by smtp.gmail.com with ESMTPSA id n64sm83680882pfi.19.2015.12.29.06.09.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Dec 2015 06:09:03 -0800 (PST) Sender: Kubilay Kocak Reply-To: koobs@FreeBSD.org Subject: Re: D-link wireless not detected References: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> <20151229103348.29c9469c@planb.netng.org> <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> <5682580B.30107@selasky.org> <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> <56825E74.3050609@selasky.org> <1EC3E6CB-5031-46F3-A3AD-329DB1FDC882@cs.huji.ac.il> <56827D08.2070602@selasky.org> <5682801B.6020404@selasky.org> <5682927B.6020704@selasky.org> <56829387.7080508@selasky.org> To: Hans Petter Selasky , Daniel Braniss Cc: Andriy Voskoboinyk , freebsd-wireless@FreeBSD.org, freebsd-arm@freebsd.org, freebsd-current@FreeBSD.org From: Kubilay Kocak Message-ID: <568293F8.3040905@FreeBSD.org> Date: Wed, 30 Dec 2015 01:08:56 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Thunderbird/42.0 MIME-Version: 1.0 In-Reply-To: <56829387.7080508@selasky.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 14:09:04 -0000 On 30/12/2015 1:07 AM, Hans Petter Selasky wrote: > On 12/29/15 15:02, Hans Petter Selasky wrote: >> On 12/29/15 14:00, Daniel Braniss wrote: >>> >>>> On 29 Dec 2015, at 14:44, Hans Petter Selasky wrote: >>>> >>>> On 12/29/15 13:36, Daniel Braniss wrote: >>>>> >>>> >>>> Until /etc/devd/usb.conf is regenerated, you'll need to manually load >>>> the kernel module for urtwn. Did you do that? >>>> >>>> --HPS >>>> >>> ok, set if_urtwn_load=yes >>> and now I get: >>> >>> ugen0.4: at usbus0 >>> urtwn0: on usbus0 >>> urtwn0: could not allocate USB transfers, err=USB_ERR_NO_PIPE >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on write >>> trapframe: 0xda29fb88 >>> FSR=00000805, FAR=00000000, spsr=60000013 >>> r0 =00000000, r1 =00000000, r2 =c0a72cb0, r3 =00000165 >>> r4 =c2cd0000, r5 =c0a86650, r6 =c2cd1a80, r7 =00000000 >>> r8 =c2cd1dd8, r9 =c2cd1a20, r10=c2a85dd0, r11=da29fc20 >>> r12=00000000, ssp=da29fc18, slr=00000004, pc =c0a3f7cc >>> >>> [ thread pid 13 tid 100045 ] >>> Stopped at ieee80211_ifdetach+0x4c: str r0, [r1] >>> db> >>> >>> btw, as long as you are willing to help, I will keep testing, >>> in other words, i’m ok. >> >> Hi Andriy, >> >> Can you fix the crash above and verify this error patch? >> > > Hi, > > I see 11-current has a fix. Maybe MFC that to 10-stable? Is there a Bugzilla issue ID for it? >> Andriy: >> >> After: >> usbd_transfer_unsetup(sc->sc_xfer, URTWN_N_TRANSFER); >> There is no need for: >> usbd_transfer_drain(sc->sc_xfer[x]); > > --HPS > From owner-freebsd-arm@freebsd.org Tue Dec 29 14:14:19 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69803A55D7A; Tue, 29 Dec 2015 14:14:19 +0000 (UTC) (envelope-from andriyvos@gmail.com) Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) (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 EF06C1D8C; Tue, 29 Dec 2015 14:14:18 +0000 (UTC) (envelope-from andriyvos@gmail.com) Received: by mail-lf0-f44.google.com with SMTP id y184so212604687lfc.1; Tue, 29 Dec 2015 06:14:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=content-type:to:subject:references:date:cc:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=sS0Us8C/fcishtPT0it8WGOESQsqutlk6Q3xQCCF6Ko=; b=hKOx9s16P0BxzafdzBnBj70v5WfN9XFutjpHKRyQ24b6nOXus9uf3kUkDV7HakFXAY ovskyAuJdNZLbJUuOLoaiftsJRRAZCBZWzO5d6r+A+4lTgxAoONV7YstddNe/8O6muOz chMk/FYGF3WwBGiMhtXouDjA/B3LjLVJfkNjmElEfMTs5ICtX0pCoSpgXK/zOSM0Mag5 qEQ1JAwpOk9hggHq7TJOOEmwHmr1MaIOT3kiV/uAEB48BK1BZcfI0QaFeazHiKZH229c 9h1jyvrlPnTdHfK+D/hCoAnmCEru9CF2X1I3BWV/8YnZL9b32MHVd/gXa9gjWsvkVQhx a+HQ== X-Received: by 10.25.91.139 with SMTP id p133mr610236lfb.108.1451398450602; Tue, 29 Dec 2015 06:14:10 -0800 (PST) Received: from localhost ([77.91.171.160]) by smtp.gmail.com with ESMTPSA id h8sm11047917lbd.5.2015.12.29.06.14.09 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 29 Dec 2015 06:14:10 -0800 (PST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Kubilay Kocak" Subject: Re: D-link wireless not detected References: <1BA8A509-38E0-4975-BD66-95D934D9E055@cs.huji.ac.il> <20151229103348.29c9469c@planb.netng.org> <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> <5682580B.30107@selasky.org> <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> <56825E74.3050609@selasky.org> <1EC3E6CB-5031-46F3-A3AD-329DB1FDC882@cs.huji.ac.il> <56827D08.2070602@selasky.org> <5682801B.6020404@selasky.org> <5682927B.6020704@selasky.org> <56829387.7080508@selasky.org> <568293F8.3040905@FreeBSD.org> Date: Tue, 29 Dec 2015 16:14:08 +0200 Cc: "Hans Petter Selasky" , "Daniel Braniss" , "freebsd-wireless@freebsd.org" , freebsd-arm@freebsd.org, freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: <568293F8.3040905@FreeBSD.org> User-Agent: Opera Mail/12.16 (FreeBSD) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 14:14:19 -0000 Tue, 29 Dec 2015 16:08:56 +0200 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Kubilay Kocak = : > On 30/12/2015 1:07 AM, Hans Petter Selasky wrote: >> On 12/29/15 15:02, Hans Petter Selasky wrote: >>> On 12/29/15 14:00, Daniel Braniss wrote: >>>> >>>>> On 29 Dec 2015, at 14:44, Hans Petter Selasky = >>>>> wrote: >>>>> >>>>> On 12/29/15 13:36, Daniel Braniss wrote: >>>>>> >>>>> >>>>> Until /etc/devd/usb.conf is regenerated, you'll need to manually l= oad >>>>> the kernel module for urtwn. Did you do that? >>>>> >>>>> --HPS >>>>> >>>> ok, set if_urtwn_load=3Dyes >>>> and now I get: >>>> >>>> ugen0.4: at usbus0 >>>> urtwn0: on usbus0 >>>> urtwn0: could not allocate USB transfers, err=3DUSB_ERR_NO_PIPE >>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on write >>>> trapframe: 0xda29fb88 >>>> FSR=3D00000805, FAR=3D00000000, spsr=3D60000013 >>>> r0 =3D00000000, r1 =3D00000000, r2 =3Dc0a72cb0, r3 =3D00000165 >>>> r4 =3Dc2cd0000, r5 =3Dc0a86650, r6 =3Dc2cd1a80, r7 =3D00000000 >>>> r8 =3Dc2cd1dd8, r9 =3Dc2cd1a20, r10=3Dc2a85dd0, r11=3Dda29fc20 >>>> r12=3D00000000, ssp=3Dda29fc18, slr=3D00000004, pc =3Dc0a3f7cc >>>> >>>> [ thread pid 13 tid 100045 ] >>>> Stopped at ieee80211_ifdetach+0x4c: str r0, [r1] >>>> db> >>>> >>>> btw, as long as you are willing to help, I will keep testing, >>>> in other words, i=E2=80=99m ok. >>> >>> Hi Andriy, >>> >>> Can you fix the crash above and verify this error patch? >>> >> >> Hi, >> >> I see 11-current has a fix. Maybe MFC that to 10-stable? > > Is there a Bugzilla issue ID for it? No, it was fixed in r292174 (as a part of = https://reviews.freebsd.org/D4447) > >>> Andriy: >>> >>> After: >>> usbd_transfer_unsetup(sc->sc_xfer, URTWN_N_TRANSFER); >>> There is no need for: >>> usbd_transfer_drain(sc->sc_xfer[x]); >> >> --HPS >> > > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to = > "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Tue Dec 29 14:20:25 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E29FAA55FFF; Tue, 29 Dec 2015 14:20:25 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 85E34115B; Tue, 29 Dec 2015 14:20:25 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.14.9/8.14.9) with ESMTP id tBTEJgDx016182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Dec 2015 22:19:42 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.14.9/8.14.9/Submit) id tBTEJfh4016181; Tue, 29 Dec 2015 22:19:41 +0800 (CST) (envelope-from kevlo) Date: Tue, 29 Dec 2015 22:19:40 +0800 From: Kevin Lo To: Hans Petter Selasky Cc: Daniel Braniss , freebsd-wireless@FreeBSD.org, freebsd-arm@freebsd.org, freebsd-current@FreeBSD.org Subject: Re: D-link wireless not detected Message-ID: <20151229141940.GA16117@ns.kevlo.org> References: <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> <5682580B.30107@selasky.org> <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> <56825E74.3050609@selasky.org> <1EC3E6CB-5031-46F3-A3AD-329DB1FDC882@cs.huji.ac.il> <56827D08.2070602@selasky.org> <5682801B.6020404@selasky.org> <5682927B.6020704@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5682927B.6020704@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 14:20:26 -0000 On Tue, Dec 29, 2015 at 03:02:35PM +0100, Hans Petter Selasky wrote: > On 12/29/15 14:00, Daniel Braniss wrote: > > > >> On 29 Dec 2015, at 14:44, Hans Petter Selasky wrote: > >> > >> On 12/29/15 13:36, Daniel Braniss wrote: > >>> > >> > >> Until /etc/devd/usb.conf is regenerated, you'll need to manually load the kernel module for urtwn. Did you do that? > >> > >> --HPS > >> > > ok, set if_urtwn_load=yes > > and now I get: > > > > ugen0.4: at usbus0 > > urtwn0: on usbus0 > > urtwn0: could not allocate USB transfers, err=USB_ERR_NO_PIPE > > Fatal kernel mode data abort: 'Translation Fault (L1)' on write > > trapframe: 0xda29fb88 > > FSR=00000805, FAR=00000000, spsr=60000013 > > r0 =00000000, r1 =00000000, r2 =c0a72cb0, r3 =00000165 > > r4 =c2cd0000, r5 =c0a86650, r6 =c2cd1a80, r7 =00000000 > > r8 =c2cd1dd8, r9 =c2cd1a20, r10=c2a85dd0, r11=da29fc20 > > r12=00000000, ssp=da29fc18, slr=00000004, pc =c0a3f7cc > > > > [ thread pid 13 tid 100045 ] > > Stopped at ieee80211_ifdetach+0x4c: str r0, [r1] > > db> > > > > btw, as long as you are willing to help, I will keep testing, > > in other words, i’m ok. > > Hi Andriy, > > Can you fix the crash above and verify this error patch? > > Andriy: > > After: > usbd_transfer_unsetup(sc->sc_xfer, URTWN_N_TRANSFER); > There is no need for: > usbd_transfer_drain(sc->sc_xfer[x]); As I mentioned previously we don't support rtl8192eu. One difference between those is the the number of endpoints and its addresses. > --HPS From owner-freebsd-arm@freebsd.org Tue Dec 29 15:23:48 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D0FDA555FE for ; Tue, 29 Dec 2015 15:23:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 67CA91328 for ; Tue, 29 Dec 2015 15:23:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 64703A555FD; Tue, 29 Dec 2015 15:23:48 +0000 (UTC) Delivered-To: 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 640AAA555FC for ; Tue, 29 Dec 2015 15:23:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DA15E1327 for ; Tue, 29 Dec 2015 15:23:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tBTFNf9m059812 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 29 Dec 2015 17:23:41 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tBTFNf9m059812 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tBTFNftR059811; Tue, 29 Dec 2015 17:23:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 29 Dec 2015 17:23:41 +0200 From: Konstantin Belousov To: Chris Rees Cc: arm@FreeBSD.org Subject: Re: Cross building ports amd64/armv6 Message-ID: <20151229152341.GV3625@kib.kiev.ua> References: <5681AD3F.6000202@physics.org> <20151228222531.GT3625@kib.kiev.ua> <56825C37.9070805@physics.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56825C37.9070805@physics.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 15:23:48 -0000 On Tue, Dec 29, 2015 at 10:11:03AM +0000, Chris Rees wrote: > Konstantin Belousov wrote: > It happens on the amd64 system, in an armv6 jail. So this sentence means that you are running not xinstall, but qemu. Now I understand this. > > > What are the filesystem types both for the source and destination > > files locations for failing install ? > > This is within the same filesystem- UFS. I've discovered md has nothing to > do with it-- UFS on ada0p4 also has the same issue, but only within the jail > i.e. only with the armv6 (x)install binary. > > Doesn't happen with ZFS, even if I make a new zpool and mount it inside > the jail. > > > Also, provide the ktrace -t '+f' / kdump output for the failing > > install(1) run. > > ktrace doesn't work inside the jail of course, so I made this with: > > % sudo ktrace -t '+f' jexec 278 install wrkdirs/a wrkdirs/c > > https://www.bayofrum.net/~crees/scratch/pfault Yes, this is what I asked. I do not see kernel ever returning EFAULT for some syscall, and I do not see qemu mapping either source or destination files. You have to find somebody who knows qemu and can interpret your findings. It might be our kernel problem, but it may be the qemu issue, and investigation there must start from the qemu side. Sorry for being unhelpful. From owner-freebsd-arm@freebsd.org Tue Dec 29 15:53:45 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 809EDA55F9C for ; Tue, 29 Dec 2015 15:53:45 +0000 (UTC) (envelope-from crees@physics.org) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by mx1.freebsd.org (Postfix) with ESMTP id F2B0113D6; Tue, 29 Dec 2015 15:53:44 +0000 (UTC) (envelope-from crees@physics.org) X-Trace: 255130499/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$ON_NET_AUTH_ACCEPTED/Talk_Talk_Customer/2.102.6.73/-4.0/crees@physics.org X-SBRS: -4.0 X-RemoteIP: 2.102.6.73 X-IP-MAIL-FROM: crees@physics.org X-SMTP-AUTH: bayofrum@uwclub.net X-MUA: Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DuBwAwrIJWPEkGZgJeKAECgw+IH4F5tl2GDwKBHE0BAQEBAQEHAQEBAUE/hDUBAQQ4HiIRCxgJFg8JAwIBAgEnChQGAQwIAogvAb4fAQEIAQEBAR+GVoN7OEyEQIR8AQSXBpZqDoVUjjqEbj6DdYFKAQEB X-IPAS-Result: A2DuBwAwrIJWPEkGZgJeKAECgw+IH4F5tl2GDwKBHE0BAQEBAQEHAQEBAUE/hDUBAQQ4HiIRCxgJFg8JAwIBAgEnChQGAQwIAogvAb4fAQEIAQEBAR+GVoN7OEyEQIR8AQSXBpZqDoVUjjqEbj6DdYFKAQEB X-IronPort-AV: E=Sophos;i="5.20,496,1444690800"; d="scan'208";a="255130499" X-IP-Direction: OUT Received: from host-2-102-6-73.as13285.net (HELO pegasus.bayofrum.net) ([2.102.6.73]) by smtp.pipex.tiscali.co.uk with ESMTP; 29 Dec 2015 15:53:10 +0000 Received: from [192.168.1.181] (HESTIA.bayofrum.net [192.168.1.181]) by pegasus.bayofrum.net (Postfix) with ESMTPSA id A738D19708; Tue, 29 Dec 2015 15:51:50 +0000 (GMT) Message-ID: <5682A84B.6040006@physics.org> Date: Tue, 29 Dec 2015 15:35:39 +0000 From: Chris Rees User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29 MIME-Version: 1.0 To: Brett Glass , Ian Lepore , freebsd-arm@freebsd.org Subject: Re: Getting started with freebsd-arm on Cubox-i2 References: <201512272145.OAA28860@mail.lariat.net> <1451264046.1369.21.camel@freebsd.org> <201512280230.TAA01501@mail.lariat.net> <1451272216.1369.25.camel@freebsd.org> <201512280450.VAA02387@mail.lariat.net> In-Reply-To: <201512280450.VAA02387@mail.lariat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-bayofrum-MailScanner-Information: Please contact the ISP for more information X-bayofrum-MailScanner-ID: A738D19708.A81C1 X-bayofrum-MailScanner: Found to be clean X-bayofrum-MailScanner-From: crees@physics.org X-Spam-Status: No X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 15:53:45 -0000 Brett Glass wrote: > At 08:10 PM 12/27/2015, Ian Lepore wrote: > >> Since there are no video drivers in the image you're running, there's >> no memory wasted on a framebuffer. The remaining memory is the kernel >> itself and page tables and other things that aren't accounted for by >> the vm system, which is where the numbers in top come from. > > Great! My next question: How to get more storage. When I flashed onto an > 8 GB card, booted, and then brought in the package manager, I filled the > card. If I put in a 16 GB card, will FFS automatically be expanded to > fill > the card? Or will I have to do that manually? Use the growfs rc script; touch /firstboot and it'll be done automatically on reboot. Chris -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-arm@freebsd.org Tue Dec 29 17:42:13 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7ABAA55B40; Tue, 29 Dec 2015 17:42:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::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 83D3B1D97; Tue, 29 Dec 2015 17:42:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x229.google.com with SMTP id to4so165919278igc.0; Tue, 29 Dec 2015 09:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ewfdmgcCvVzj8ej0KyiWR9pCxg9HG80tlC7Z7r76Vjo=; b=zKxrF/9vRbeBI2lTTsfIYYEM5TRhEu6s5DKP3QUugH8psN/cuFi0sDJD8jRRweVAKv Grovm1CGjVvy0mR3/PS+rMYW+JAY9Ncmlnu5asGrALZ93Eh8ebdMnSLAiN8W5kcgFr8U WQHE42RlCqn5m5+MQjD7FADYScrA0vBCTDUWgdebKkX8zrD0/ArynqLsH8cRrDYaDkKx 8ySFIhL7vqay9YmIroEvA7vznINaAISpx2Fn5o3qnAKVJG/OrdkB08no147lacVlsC9a JMqI6pHVV+arfq+a71GnY58nXE0PeGYflEV7ebnRzHnGchkhAU7c91GzRY5IOYIWiLOz AYrQ== MIME-Version: 1.0 X-Received: by 10.50.50.238 with SMTP id f14mr7380028igo.37.1451410932912; Tue, 29 Dec 2015 09:42:12 -0800 (PST) Received: by 10.36.121.202 with HTTP; Tue, 29 Dec 2015 09:42:12 -0800 (PST) In-Reply-To: <20151229141940.GA16117@ns.kevlo.org> References: <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> <5682580B.30107@selasky.org> <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> <56825E74.3050609@selasky.org> <1EC3E6CB-5031-46F3-A3AD-329DB1FDC882@cs.huji.ac.il> <56827D08.2070602@selasky.org> <5682801B.6020404@selasky.org> <5682927B.6020704@selasky.org> <20151229141940.GA16117@ns.kevlo.org> Date: Tue, 29 Dec 2015 09:42:12 -0800 Message-ID: Subject: Re: D-link wireless not detected From: Adrian Chadd To: Kevin Lo Cc: Hans Petter Selasky , "freebsd-arm@freebsd.org" , "freebsd-wireless@freebsd.org" , freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 17:42:13 -0000 I'll go order one and take a crack at it soon. (I saw this when looking at the r92su and realtek linux drivers - they do a whole bunch of extra endpoint gymnastics that we don't..) -a On 29 December 2015 at 06:19, Kevin Lo wrote: > On Tue, Dec 29, 2015 at 03:02:35PM +0100, Hans Petter Selasky wrote: >> On 12/29/15 14:00, Daniel Braniss wrote: >> > >> >> On 29 Dec 2015, at 14:44, Hans Petter Selasky wrote= : >> >> >> >> On 12/29/15 13:36, Daniel Braniss wrote: >> >>> >> >> >> >> Until /etc/devd/usb.conf is regenerated, you'll need to manually load= the kernel module for urtwn. Did you do that? >> >> >> >> --HPS >> >> >> > ok, set if_urtwn_load=3Dyes >> > and now I get: >> > >> > ugen0.4: at usbus0 >> > urtwn0: on usbus0 >> > urtwn0: could not allocate USB transfers, err=3DUSB_ERR_NO_PIPE >> > Fatal kernel mode data abort: 'Translation Fault (L1)' on write >> > trapframe: 0xda29fb88 >> > FSR=3D00000805, FAR=3D00000000, spsr=3D60000013 >> > r0 =3D00000000, r1 =3D00000000, r2 =3Dc0a72cb0, r3 =3D00000165 >> > r4 =3Dc2cd0000, r5 =3Dc0a86650, r6 =3Dc2cd1a80, r7 =3D00000000 >> > r8 =3Dc2cd1dd8, r9 =3Dc2cd1a20, r10=3Dc2a85dd0, r11=3Dda29fc20 >> > r12=3D00000000, ssp=3Dda29fc18, slr=3D00000004, pc =3Dc0a3f7cc >> > >> > [ thread pid 13 tid 100045 ] >> > Stopped at ieee80211_ifdetach+0x4c: str r0, [r1] >> > db> >> > >> > btw, as long as you are willing to help, I will keep testing, >> > in other words, i=E2=80=99m ok. >> >> Hi Andriy, >> >> Can you fix the crash above and verify this error patch? >> >> Andriy: >> >> After: >> usbd_transfer_unsetup(sc->sc_xfer, URTWN_N_TRANSFER); >> There is no need for: >> usbd_transfer_drain(sc->sc_xfer[x]); > > As I mentioned previously we don't support rtl8192eu. One difference > between those is the the number of endpoints and its addresses. > >> --HPS > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Tue Dec 29 19:54:55 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45961A55BFC for ; Tue, 29 Dec 2015 19:54:55 +0000 (UTC) (envelope-from crees@physics.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 292FA1B9A for ; Tue, 29 Dec 2015 19:54:55 +0000 (UTC) (envelope-from crees@physics.org) Received: by mailman.ysv.freebsd.org (Postfix) id 270D7A55BFB; Tue, 29 Dec 2015 19:54:55 +0000 (UTC) Delivered-To: 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 269DEA55BFA for ; Tue, 29 Dec 2015 19:54:55 +0000 (UTC) (envelope-from crees@physics.org) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by mx1.freebsd.org (Postfix) with ESMTP id BC0881B99 for ; Tue, 29 Dec 2015 19:54:54 +0000 (UTC) (envelope-from crees@physics.org) X-Trace: 260521161/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$ON_NET_AUTH_ACCEPTED/Talk_Talk_Customer/2.102.6.73/-4.0/crees@physics.org X-SBRS: -4.0 X-RemoteIP: 2.102.6.73 X-IP-MAIL-FROM: crees@physics.org X-SMTP-AUTH: bayofrum@uwclub.net X-MUA: Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AGCACq5IJWPEkGZgJeKAECgw9SbYhZtl8ihW0CgRxNAQEBAQEBBwEBAQFAAT+ENQEBBCMPAQUeHgQRCxgCAgUWCwICCQMCAQIBJwoUBgEMBgICiC8BCa0ZkS4BAQEHAQEBAQEBGQSBAYVVg3s4TIdzgUkBBJcGhUCRKg6FVI46hG4+NAGFCgEBAQ X-IPAS-Result: A2AGCACq5IJWPEkGZgJeKAECgw9SbYhZtl8ihW0CgRxNAQEBAQEBBwEBAQFAAT+ENQEBBCMPAQUeHgQRCxgCAgUWCwICCQMCAQIBJwoUBgEMBgICiC8BCa0ZkS4BAQEHAQEBAQEBGQSBAYVVg3s4TIdzgUkBBJcGhUCRKg6FVI46hG4+NAGFCgEBAQ X-IronPort-AV: E=Sophos;i="5.20,496,1444690800"; d="scan'208";a="260521161" X-IP-Direction: OUT Received: from host-2-102-6-73.as13285.net (HELO pegasus.bayofrum.net) ([2.102.6.73]) by smtp.pipex.tiscali.co.uk with ESMTP; 29 Dec 2015 19:54:45 +0000 Received: from [192.168.1.181] (HESTIA.bayofrum.net [192.168.1.181]) by pegasus.bayofrum.net (Postfix) with ESMTPSA id 64762191BF; Tue, 29 Dec 2015 19:53:26 +0000 (GMT) Message-ID: <5682E0E9.3030308@physics.org> Date: Tue, 29 Dec 2015 19:37:13 +0000 From: Chris Rees User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29 MIME-Version: 1.0 To: =?UTF-8?Q?Mika=c3=abl_Urankar?= , arm@FreeBSD.org Subject: Re: Cross building ports amd64/armv6 References: <5681AD3F.6000202@physics.org> <5682B4E6.4080604@physics.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-bayofrum-MailScanner-Information: Please contact the ISP for more information X-bayofrum-MailScanner-ID: 64762191BF.AA399 X-bayofrum-MailScanner: Found to be clean X-bayofrum-MailScanner-From: crees@physics.org X-Spam-Status: No X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 19:54:55 -0000 Mikaël Urankar wrote: > 2015-12-29 17:29 GMT+01:00 Chris Rees : >>> The issue is similar to this PR [1], can you try the attached patch? >>> >>> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203852 >>> >> Sorry, no help for me. I found the other if (len == 0) return 0 and changed >> that too, but no difference. > Have you updated qemu in the jail?, ie something like cp -f > work/stage/usr/local/bin/qemu-arm-static > /usr/local/poudriere/jails/11armv6/usr/local/bin/qemu-arm-static > OK, so I had, but of course the ingenious snapshotting @clean etc was ignoring my change. Thanks very much, it works great! Would you like me to report on the PR? Chris -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-arm@freebsd.org Wed Dec 30 00:49:23 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70942A55656 for ; Wed, 30 Dec 2015 00:49:23 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4047614C6 for ; Wed, 30 Dec 2015 00:49:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id tBU0Vg95007929; Tue, 29 Dec 2015 16:31:42 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id tBU0Vgab007928; Tue, 29 Dec 2015 16:31:42 -0800 (PST) (envelope-from fbsd) Date: Tue, 29 Dec 2015 16:31:42 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Did somebody turn off ping in 11-CURRENT on rpi2? Message-ID: <20151230003142.GF29187@www.zefox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 00:49:23 -0000 In the last couple of rebuild cycles reply to ping stopped on my rpi2. It's at r292837 presently and seems to have changed around a week ago. No intentional changes have been made since then. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Wed Dec 30 01:08:16 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDB64A55FA4 for ; Wed, 30 Dec 2015 01:08:16 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A342131A for ; Wed, 30 Dec 2015 01:08:16 +0000 (UTC) (envelope-from jungleboogie0@gmail.com) Received: by mail-vk0-x236.google.com with SMTP id a188so199943886vkc.0 for ; Tue, 29 Dec 2015 17:08:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pEBIe2QU2CK2DZWSWRsWBHoZBSvH62v1yzBjevzSCiY=; b=dpx14TUSzGkIIVoMZn3RC87sUJLZOAzQuG3trd/EqqHYBJYRwIShowu0Rn7BfhwG2b tvZTs/M7Ls52tTTvu5qMWmKz6J+UlkJN41gJHsYcd3BJgFM3ZRJpp5Hg9RnfuZw15h67 2s4KHiMFzxlgBMgTAPVYydGgwF11vldhUce3l1NM1jINkEh+O0PzYdz1jbgtebhKgqbC SaGhx6j/qw5E8FtjCxbHoyvv4pvaFDbaMKI6eY0vTZ/uH5beO8BCx1JItsfQu9jQl/AX df6eyT3LOUEjSkVexBqScIaqawozJ3inEzEHPDC+5nx1qFEu1Sc8OOnqGJEr2h6rNFUC x5jQ== MIME-Version: 1.0 X-Received: by 10.31.11.204 with SMTP id 195mr41132396vkl.23.1451437695409; Tue, 29 Dec 2015 17:08:15 -0800 (PST) Received: by 10.31.56.142 with HTTP; Tue, 29 Dec 2015 17:08:15 -0800 (PST) In-Reply-To: <20151230003142.GF29187@www.zefox.net> References: <20151230003142.GF29187@www.zefox.net> Date: Tue, 29 Dec 2015 17:08:15 -0800 Message-ID: Subject: Re: Did somebody turn off ping in 11-CURRENT on rpi2? From: jungle Boogie To: bob prohaska Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 01:08:16 -0000 Hi Bob, On 29 December 2015 at 16:31, bob prohaska wrote: > In the last couple of rebuild cycles reply to ping stopped > on my rpi2. It's at r292837 presently and seems to have changed > around a week ago. No intentional changes have been made since > then. > If I'm reading this correctly, no: https://svnweb.freebsd.org/base/head/sbin/ping/?pathrev=292897 revision 282436 by brooks, Mon May 4 21:44:51 2015 UTC What doesn't work? > Thanks for reading, > > bob prohaska > -- ------- inum: 883510009027723 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si From owner-freebsd-arm@freebsd.org Wed Dec 30 01:37:21 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EDD54A566FB for ; Wed, 30 Dec 2015 01:37:21 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C633D1D10 for ; Wed, 30 Dec 2015 01:37:21 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id tBU1bKEw008101; Tue, 29 Dec 2015 17:37:20 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id tBU1bKE3008100; Tue, 29 Dec 2015 17:37:20 -0800 (PST) (envelope-from fbsd) Date: Tue, 29 Dec 2015 17:37:20 -0800 From: bob prohaska To: jungle Boogie Cc: freebsd-arm@freebsd.org Subject: Re: Did somebody turn off ping in 11-CURRENT on rpi2? Message-ID: <20151230013720.GG29187@www.zefox.net> References: <20151230003142.GF29187@www.zefox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 01:37:22 -0000 My error; the problem is on the sending side..... an iMac. Apologies to all, bob On Tue, Dec 29, 2015 at 05:08:15PM -0800, jungle Boogie wrote: > Hi Bob, > On 29 December 2015 at 16:31, bob prohaska wrote: > > In the last couple of rebuild cycles reply to ping stopped > > on my rpi2. It's at r292837 presently and seems to have changed > > around a week ago. No intentional changes have been made since > > then. > > > > If I'm reading this correctly, no: > https://svnweb.freebsd.org/base/head/sbin/ping/?pathrev=292897 > > revision 282436 by brooks, Mon May 4 21:44:51 2015 UTC > > What doesn't work? > > > Thanks for reading, > > > > bob prohaska > > > > -- > ------- > inum: 883510009027723 > sip: jungleboogie@sip2sip.info > xmpp: jungle-boogie@jit.si From owner-freebsd-arm@freebsd.org Wed Dec 30 06:55:16 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E715EA53745; Wed, 30 Dec 2015 06:55:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9DA721C80; Wed, 30 Dec 2015 06:55:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1aEAf5-000I9b-0i; Wed, 30 Dec 2015 08:55:07 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: D-link wireless not detected From: Daniel Braniss In-Reply-To: Date: Wed, 30 Dec 2015 08:55:06 +0200 Cc: Kevin Lo , "freebsd-arm@freebsd.org" , "freebsd-wireless@freebsd.org" , Hans Petter Selasky , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <382E50DE-7B65-4469-9851-8F28A335096C@cs.huji.ac.il> <5682580B.30107@selasky.org> <346C6669-E51E-498F-8AD0-C294F70B441D@cs.huji.ac.il> <56825E74.3050609@selasky.org> <1EC3E6CB-5031-46F3-A3AD-329DB1FDC882@cs.huji.ac.il> <56827D08.2070602@selasky.org> <5682801B.6020404@selasky.org> <5682927B.6020704@selasky.org> <20151229141940.GA16117@ns.kevlo.org> To: Adrian Chadd X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 06:55:16 -0000 > On 29 Dec 2015, at 19:42, Adrian Chadd wrote: >=20 > I'll go order one and take a crack at it soon. >=20 > (I saw this when looking at the r92su and realtek linux drivers - they > do a whole bunch of extra endpoint gymnastics that we don't..) great, let me know, and I can help out debugging. danny >=20 >=20 > -a >=20 >=20 > On 29 December 2015 at 06:19, Kevin Lo wrote: >> On Tue, Dec 29, 2015 at 03:02:35PM +0100, Hans Petter Selasky wrote: >>> On 12/29/15 14:00, Daniel Braniss wrote: >>>>=20 >>>>> On 29 Dec 2015, at 14:44, Hans Petter Selasky = wrote: >>>>>=20 >>>>> On 12/29/15 13:36, Daniel Braniss wrote: >>>>>>=20 >>>>>=20 >>>>> Until /etc/devd/usb.conf is regenerated, you'll need to manually = load the kernel module for urtwn. Did you do that? >>>>>=20 >>>>> --HPS >>>>>=20 >>>> ok, set if_urtwn_load=3Dyes >>>> and now I get: >>>>=20 >>>> ugen0.4: at usbus0 >>>> urtwn0: on usbus0 >>>> urtwn0: could not allocate USB transfers, err=3DUSB_ERR_NO_PIPE >>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on write >>>> trapframe: 0xda29fb88 >>>> FSR=3D00000805, FAR=3D00000000, spsr=3D60000013 >>>> r0 =3D00000000, r1 =3D00000000, r2 =3Dc0a72cb0, r3 =3D00000165 >>>> r4 =3Dc2cd0000, r5 =3Dc0a86650, r6 =3Dc2cd1a80, r7 =3D00000000 >>>> r8 =3Dc2cd1dd8, r9 =3Dc2cd1a20, r10=3Dc2a85dd0, r11=3Dda29fc20 >>>> r12=3D00000000, ssp=3Dda29fc18, slr=3D00000004, pc =3Dc0a3f7cc >>>>=20 >>>> [ thread pid 13 tid 100045 ] >>>> Stopped at ieee80211_ifdetach+0x4c: str r0, [r1] >>>> db> >>>>=20 >>>> btw, as long as you are willing to help, I will keep testing, >>>> in other words, i=E2=80=99m ok. >>>=20 >>> Hi Andriy, >>>=20 >>> Can you fix the crash above and verify this error patch? >>>=20 >>> Andriy: >>>=20 >>> After: >>> usbd_transfer_unsetup(sc->sc_xfer, URTWN_N_TRANSFER); >>> There is no need for: >>> usbd_transfer_drain(sc->sc_xfer[x]); >>=20 >> As I mentioned previously we don't support rtl8192eu. One difference >> between those is the the number of endpoints and its addresses. >>=20 >>> --HPS >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Dec 30 16:48:30 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3CC47A55FAE for ; Wed, 30 Dec 2015 16:48:30 +0000 (UTC) (envelope-from la5lbtyi@aon.at) Received: from smtpout-fallback.aon.at (smtpout-fallback.aon.at [195.3.96.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8AD5E1628 for ; Wed, 30 Dec 2015 16:48:28 +0000 (UTC) (envelope-from la5lbtyi@aon.at) Received: (qmail 2018 invoked from network); 30 Dec 2015 16:41:45 -0000 Received: from unknown (HELO smtpout.aon.at) ([172.18.1.201]) (envelope-sender ) by fallback43.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 30 Dec 2015 16:41:45 -0000 Received: (qmail 16156 invoked from network); 30 Dec 2015 16:41:38 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on WARSBL606.highway.telekom.at X-Spam-Level: Received: from 194-166-159-156.adsl.highway.telekom.at (HELO gandalf.xyzzy) ([194.166.159.156]) (envelope-sender ) by smarthub81.res.a1.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 30 Dec 2015 16:41:37 -0000 X-A1Mail-Track-Id: 1451493697:16123:smarthub81:194.166.159.156:1 Received: from mizar.xyzzy (mizar.xyzzy [192.168.1.19]) by gandalf.xyzzy (8.15.2/8.15.2) with ESMTP id tBUGfaRG019176 for ; Wed, 30 Dec 2015 17:41:37 +0100 (CET) (envelope-from la5lbtyi@aon.at) To: freebsd-arm@freebsd.org From: Martin Birgmeier Subject: Booting a RPI 1 B+ X-Enigmail-Draft-Status: N1110 Organization: MBi at home Message-ID: <56840940.20709@aon.at> Date: Wed, 30 Dec 2015 17:41:36 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 16:48:30 -0000 I have prepared a (16 GB) micro SDHC card from ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/10.2/Fre= eBSD-10.2-STABLE-arm-armv6-RPI-B-20151229-r292855.img.xz (i.e., dd'd the 480 MB to the card). I have a barebones RPI 1 B+ into which I insert the card. The only available connection is via Ethernet, i.e., no monitor, no keyboard, no serial. After applying power something seems to happen in that after a while, the Ethernet LEDs on the RPI blink in a way typical for Ethernet. However, that's it, specifically my DHCP server never receives a request, nor does the RPI in any way become accessible via Ethernet. In fact, not a single Ethernet frame reaches the DHCP server (checked via tcpdump). After shutting down and doing a binary comparison of the card's contents with the image, there are very few changes; mounting the image and the card and then doing a diff -r shows no differences at all. The filesystem on the card also has not been resized. The RPI runs its original Linux fine. Any pointers as to what is going on? -- Martin From owner-freebsd-arm@freebsd.org Wed Dec 30 21:37:03 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62222A55457 for ; Wed, 30 Dec 2015 21:37:03 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [220.233.87.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1E911C4E for ; Wed, 30 Dec 2015 21:37:02 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id tBULLwLB021452 for ; Thu, 31 Dec 2015 08:21:58 +1100 (AEDT) (envelope-from freebsd-arm@sentry.org) Subject: Re: Booting a RPI 1 B+ To: freebsd-arm@freebsd.org References: <56840940.20709@aon.at> From: Trev Message-ID: <56844AF6.1050504@sentry.org> Date: Thu, 31 Dec 2015 08:21:58 +1100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <56840940.20709@aon.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (shadow.sentry.org [127.0.0.1]); Thu, 31 Dec 2015 08:21:58 +1100 (AEDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 21:37:03 -0000 Martin Birgmeier wrote: > I have prepared a (16 GB) micro SDHC card What brand SDHC card? Anecdotally, Kingston cards fail while SanDisk and Patriot work. From owner-freebsd-arm@freebsd.org Wed Dec 30 21:51:06 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2FA83A55A05 for ; Wed, 30 Dec 2015 21:51:06 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (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 09C651FBF for ; Wed, 30 Dec 2015 21:51:06 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=SIdxVMkWPncAA8+Im2S9g3at0shWzVTozVUTw+sXp/Y=; b=vNouSlqCNe2h5CWqcilTeOhu+g sB6j96ML6eGV8zPnmM4BxslbnSJZFUD/DKjdBDWi0CIGzUVLNSjTDteZ9mVolbK8g7zA3ZtRa2G4a 6TvkH5lVPcXKOpLB4h4W0TDOKi+Ae9fsiPEtaURaFFyha0VzN7Em4smGQMA7raxtETS4=; Received: from [114.121.132.122] (port=56121 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aEOe1-001sPk-Rn; Wed, 30 Dec 2015 14:50:58 -0700 Date: Thu, 31 Dec 2015 05:50:51 +0800 From: Erich Dollansky To: Martin Birgmeier Cc: freebsd-arm@freebsd.org Subject: Re: Booting a RPI 1 B+ Message-ID: <20151231055051.119d587a@X220.alogt.com> In-Reply-To: <56840940.20709@aon.at> References: <56840940.20709@aon.at> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Authenticated-Sender: sl-508-2.slc.westdc.net: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 21:51:06 -0000 Hi, On Wed, 30 Dec 2015 17:41:36 +0100 Martin Birgmeier wrote: > I have prepared a (16 GB) micro SDHC card from > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/10.2/FreeBSD-10.2-STABLE-arm-armv6-RPI-B-20151229-r292855.img.xz > (i.e., dd'd the 480 MB to the card). > I use Samsung and SanDisk with success. I also found out that FreeBSD 11 has a higher chance of booting than 10.2. 10.2 is more picky about the cards in use. You can also take the card out and back to a running machine and check the settings in /etc/rc.conf. The file system should use after the first start the full capacity. If not, the system never started. Erich From owner-freebsd-arm@freebsd.org Wed Dec 30 23:38:15 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD35FA5693A for ; Wed, 30 Dec 2015 23:38:15 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (kientzle.com [142.254.26.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43C661F17 for ; Wed, 30 Dec 2015 23:38:13 +0000 (UTC) (envelope-from tim@kientzle.com) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id tBUNc0iI007583; Wed, 30 Dec 2015 23:38:00 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.112] (192.168.1.101 [192.168.1.101]) by kientzle.com with SMTP id 8wvhw39hz46xzcr8drpgtwea76; Wed, 30 Dec 2015 23:37:59 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Booting a RPI 1 B+ From: Tim Kientzle In-Reply-To: <56840940.20709@aon.at> Date: Wed, 30 Dec 2015 15:36:41 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <56840940.20709@aon.at> To: Martin Birgmeier X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 23:38:15 -0000 > On Dec 30, 2015, at 8:41 AM, Martin Birgmeier wrote: >=20 > I have prepared a (16 GB) micro SDHC card from > = ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/10.2/Free= BSD-10.2-STABLE-arm-armv6-RPI-B-20151229-r292855.img.xz > (i.e., dd'd the 480 MB to the card). >=20 > I have a barebones RPI 1 B+ into which I insert the card. The only > available connection is via Ethernet, i.e., no monitor, no keyboard, = no > serial. >=20 > After applying power something seems to happen in that after a while, > the Ethernet LEDs on the RPI blink in a way typical for Ethernet. > However, that's it, specifically my DHCP server never receives a > request, nor does the RPI in any way become accessible via Ethernet. = In > fact, not a single Ethernet frame reaches the DHCP server (checked via > tcpdump). >=20 > After shutting down and doing a binary comparison of the card's = contents > with the image, there are very few changes; mounting the image and the > card and then doing a diff -r shows no differences at all. The > filesystem on the card also has not been resized. >=20 > The RPI runs its original Linux fine. >=20 > Any pointers as to what is going on? You should consider getting a USB serial adapter cable such as: http://adafru.it/954 This will let you see the earliest boot messages and any errors that may = be appearing. As others have mentioned, it's worth trying different SDHC cards, since = the SD drivers do not seem to be compatible with all cards. Tim From owner-freebsd-arm@freebsd.org Thu Dec 31 08:48:00 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B671CA561B9 for ; Thu, 31 Dec 2015 08:48:00 +0000 (UTC) (envelope-from la5lbtyi@aon.at) Received: from smtpout-fallback.aon.at (smtpout-fallback.aon.at [195.3.96.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 181111EA2 for ; Thu, 31 Dec 2015 08:47:59 +0000 (UTC) (envelope-from la5lbtyi@aon.at) Received: (qmail 11578 invoked from network); 31 Dec 2015 08:47:55 -0000 Received: from unknown (HELO smtpout.aon.at) ([172.18.1.205]) (envelope-sender ) by fallback43.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 31 Dec 2015 08:47:55 -0000 Received: (qmail 23473 invoked from network); 31 Dec 2015 08:47:47 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on WARSBL604.highway.telekom.at X-Spam-Level: Received: from 178-191-48-124.adsl.highway.telekom.at (HELO gandalf.xyzzy) ([178.191.48.124]) (envelope-sender ) by smarthub77.res.a1.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP; 31 Dec 2015 08:47:47 -0000 X-A1Mail-Track-Id: 1451551666:23450:smarthub77:178.191.48.124:1 Received: from mizar.xyzzy (mizar.xyzzy [192.168.1.19]) by gandalf.xyzzy (8.15.2/8.15.2) with ESMTP id tBV8lj3A006811; Thu, 31 Dec 2015 09:47:46 +0100 (CET) (envelope-from la5lbtyi@aon.at) Subject: Re: Booting a RPI 1 B+ To: Erich Dollansky References: <56840940.20709@aon.at> <20151231055051.119d587a@X220.alogt.com> Cc: freebsd-arm@freebsd.org From: Martin Birgmeier Organization: MBi at home Message-ID: <5684EBB1.40205@aon.at> Date: Thu, 31 Dec 2015 09:47:45 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151231055051.119d587a@X220.alogt.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2015 08:48:00 -0000 Thank you everyone for all the tips. It turned out that the 11.0 image ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0/FreeBSD-11.0-CURRENT-arm-armv6-RPI-B-20151229-r292858.img.xz worked immediately. -- Martin On 12/30/15 22:50, Erich Dollansky wrote: > Hi, > > On Wed, 30 Dec 2015 17:41:36 +0100 > Martin Birgmeier wrote: > >> I have prepared a (16 GB) micro SDHC card from >> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/10.2/FreeBSD-10.2-STABLE-arm-armv6-RPI-B-20151229-r292855.img.xz >> (i.e., dd'd the 480 MB to the card). >> > I use Samsung and SanDisk with success. > > I also found out that FreeBSD 11 has a higher chance of booting than > 10.2. 10.2 is more picky about the cards in use. > > You can also take the card out and back to a running machine and check > the settings in /etc/rc.conf. The file system should use after the > first start the full capacity. If not, the system never started. > > Erich > > From owner-freebsd-arm@freebsd.org Thu Dec 31 19:34:25 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78959A5719F for ; Thu, 31 Dec 2015 19:34:25 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C403197E for ; Thu, 31 Dec 2015 19:34:24 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1451590309; bh=6iEybgLGOMEW+y9oovmheeZC3iKNf/KH1k0p5W93MKE=; h=From:Subject:Date:To:From:Subject; b=gJMYT/5YNA2FOgy6mOmCDTX/jPDGyOL0w0Oexd1074mRwl1ZyLAkLHN5aineZGAsj8h+m9A3F7W4q0G42YI2Bk7rnX+nTDsGJwI8LyBfH0Z1/gWOiDA7ibqB2oCck5DWYQizwRVdoCQuueints350RqCWH/gvJod0DVEAowhisepMlYKW5dBYrYTGyo3s13el6F80u1Vf7zZy3C3nTLG3UxeoLoFtKfLGDZ7rTXE65JOKL22fuUT5iDa6we3+/xRQkXJrvTBs9vYkOYnWy+tEmOymPrgU0xeEHyonNjmdyO2yKAxmpH8Zj/w4iJYFD3VDT7NbTZMy1yNy5Yxgs3BhQ== Received: from [98.139.215.142] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 31 Dec 2015 19:31:49 -0000 Received: from [98.139.211.206] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 31 Dec 2015 19:31:49 -0000 Received: from [127.0.0.1] by smtp215.mail.bf1.yahoo.com with NNFMP; 31 Dec 2015 19:31:49 -0000 X-Yahoo-Newman-Id: 781177.92999.bm@smtp215.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6.g26F0VM1ki2XSRitMEVz1r49zD25MT3L2zq0k8KHuIqlK lCdRk.ojhE.Zpf1Vkzatv4u_LCg6IhAd1Ve0iXB8oAPMqjHUVaWvTEwKj_bi dAcaarlijj..486wQ.lvyom.iD9HMNQ6KzbjLCX7uhJ3fOcQY.i4wW0y0Ty6 e32rfUyUfz7K9bUgBQpkT7vw26Wjg6OwmD7y64v486kAV3ZrGpd7Qeqvcccs qakucItybn6wQ2_lgkWo7jkMofFUu0YEdANKaYTbaBTIiMdPwwTTOd3VXupR 3T_UF5R2578u_6_iGB_UCQEQ2Dr3MbD2M2k.ti5V1pmgULo_RObD3.Ew8hsI n6st092GbO5J5UVk09r7yWP71GN.sZYKHunNe0ueNc5sX65vIjVi.9Ss1Rk6 Vik5zSG1ToeT3lF5P9qlZzm_X8c3JpS0LMAF6LsoaCHRnS2VQoNSK9Kjw4js vos.JLVA.x5Oz1RsOt9UFnqEjJsiTipdbLWveXDWwiquirgC5AZ_hTqOV1dS dP7Jkk1yH2ZDBzem_MkAdGMzAZvKPLiPs1VPqMFFOeDAf6A-- X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV From: Thomas Skibo Content-Type: multipart/mixed; boundary="Apple-Mail=_F075A616-44A9-4C1F-98E9-03F8A745328B" Subject: Re: u-boot and ubldr on arm64 Message-Id: <5A031837-F7D6-467F-A6B7-35B1F0A467D9@yahoo.com> Date: Thu, 31 Dec 2015 11:31:47 -0800 To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2015 19:34:25 -0000 --Apple-Mail=_F075A616-44A9-4C1F-98E9-03F8A745328B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello. Attached is the corrected patch for supporting ubldr on arm64. Happy New Year! =E2=80=94Thomas =E2=80=94=E2=80=94 Thomas Skibo thomasskibo@yahoo.com --Apple-Mail=_F075A616-44A9-4C1F-98E9-03F8A745328B Content-Disposition: attachment; filename=ubldr-patches.txt Content-Type: text/plain; name="ubldr-patches.txt" Content-Transfer-Encoding: quoted-printable Index: sys/boot/Makefile.arm64 =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 --- sys/boot/Makefile.arm64 (revision 292987) +++ sys/boot/Makefile.arm64 (working copy) @@ -4,4 +4,4 @@ SUBDIR+=3D fdt .endif =20 -SUBDIR+=3D efi +SUBDIR+=3D efi uboot Index: sys/boot/arm64/Makefile =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 --- sys/boot/arm64/Makefile (revision 292987) +++ sys/boot/arm64/Makefile (working copy) @@ -1,3 +1,5 @@ # $FreeBSD$ =20 +SUBDIR=3D uboot + .include Index: sys/boot/arm64/Makefile.inc =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 --- sys/boot/arm64/Makefile.inc (nonexistent) +++ sys/boot/arm64/Makefile.inc (working copy) @@ -0,0 +1,3 @@ +# $FreeBSD$ + +.include "../Makefile.inc" Property changes on: sys/boot/arm64/Makefile.inc ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=3D%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: sys/boot/arm64/uboot/Makefile =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 --- sys/boot/arm64/uboot/Makefile (nonexistent) +++ sys/boot/arm64/uboot/Makefile (working copy) @@ -0,0 +1,159 @@ +# $FreeBSD$ + +.include + +FILES=3D ubldr ubldr.bin + +NEWVERSWHAT=3D "U-Boot loader" ${MACHINE_ARCH} +BINDIR?=3D /boot +INSTALLFLAGS=3D -b +WARNS?=3D 1 +# Address at which ubldr will be loaded. +# This varies for different boards and SOCs. +UBLDR_LOADADDR?=3D 0x1000000 + +# Architecture-specific loader code +SRCS=3D start.S conf.c self_reloc.c vers.c + +.if !defined(LOADER_NO_DISK_SUPPORT) +LOADER_DISK_SUPPORT?=3D yes +.else +LOADER_DISK_SUPPORT=3D no +.endif +LOADER_UFS_SUPPORT?=3D yes +LOADER_CD9660_SUPPORT?=3D no +LOADER_EXT2FS_SUPPORT?=3D no +.if ${MK_NAND} !=3D "no" +LOADER_NANDFS_SUPPORT?=3D yes +.else +LOADER_NANDFS_SUPPORT?=3D no +.endif +LOADER_NET_SUPPORT?=3D yes +LOADER_NFS_SUPPORT?=3D yes +LOADER_TFTP_SUPPORT?=3D no +LOADER_GZIP_SUPPORT?=3D no +LOADER_BZIP2_SUPPORT?=3D no +.if ${MK_FDT} !=3D "no" +LOADER_FDT_SUPPORT=3D yes +.else +LOADER_FDT_SUPPORT=3D no +.endif + +.if ${LOADER_DISK_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_DISK_SUPPORT +.endif +.if ${LOADER_UFS_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_UFS_SUPPORT +.endif +.if ${LOADER_CD9660_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_CD9660_SUPPORT +.endif +.if ${LOADER_EXT2FS_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_EXT2FS_SUPPORT +.endif +.if ${LOADER_NANDFS_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_NANDFS_SUPPORT +.endif +.if ${LOADER_GZIP_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_GZIP_SUPPORT +.endif +.if ${LOADER_BZIP2_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_BZIP2_SUPPORT +.endif +.if ${LOADER_NET_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_NET_SUPPORT +.endif +.if ${LOADER_NFS_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_NFS_SUPPORT +.endif +.if ${LOADER_TFTP_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_TFTP_SUPPORT +.endif +.if ${LOADER_FDT_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -I${.CURDIR}/../../fdt +CFLAGS+=3D -I${.OBJDIR}/../../fdt +CFLAGS+=3D -DLOADER_FDT_SUPPORT +LIBUBOOT_FDT=3D ${.OBJDIR}/../../uboot/fdt/libuboot_fdt.a +LIBFDT=3D ${.OBJDIR}/../../fdt/libfdt.a +.endif + +CFLAGS+=3D -DNETIF_OPEN_CLOSE_ONCE + +.if ${MK_FORTH} !=3D "no" +# Enable BootForth +BOOT_FORTH=3D yes +CFLAGS+=3D -DBOOT_FORTH -I${.CURDIR}/../../ficl = -I${.CURDIR}/../../ficl/aarch64 +LIBFICL=3D ${.OBJDIR}/../../ficl/libficl.a +.endif + +# Always add MI sources +.PATH: ${.CURDIR}/../../common +.include "${.CURDIR}/../../common/Makefile.inc" +CFLAGS+=3D -I${.CURDIR}/../../common +CFLAGS+=3D -I. + +CLEANFILES+=3D vers.c loader.help + +CFLAGS+=3D -ffreestanding -msoft-float + +LDFLAGS=3D -nostdlib -static -T = ${.CURDIR}/ldscript.${MACHINE_CPUARCH} + +# Pull in common loader code +.PATH: ${.CURDIR}/../../uboot/common +.include "${.CURDIR}/../../uboot/common/Makefile.inc" +CFLAGS+=3D -I${.CURDIR}/../../uboot/common + +# U-Boot standalone support library +LIBUBOOT=3D ${.OBJDIR}/../../uboot/lib/libuboot.a +CFLAGS+=3D -I${.CURDIR}/../../uboot/lib +CFLAGS+=3D -I${.OBJDIR}/../../uboot/lib + +# where to get libstand from +CFLAGS+=3D -I${.CURDIR}/../../../../lib/libstand/ + +# clang doesn't understand %D as a specifier to printf +NO_WERROR.clang=3D + +DPADD=3D ${LIBFICL} ${LIBUBOOT} ${LIBFDT} ${LIBUBOOT_FDT} = ${LIBSTAND} +LDADD=3D ${LIBFICL} ${LIBUBOOT} ${LIBFDT} ${LIBUBOOT_FDT} = -lstand + +OBJS+=3D ${SRCS:N*.h:R:S/$/.o/g} + +vers.c: ${.CURDIR}/../../common/newvers.sh ${.CURDIR}/version + sh ${.CURDIR}/../../common/newvers.sh ${.CURDIR}/version = ${NEWVERSWHAT} + +loader.help: help.common help.uboot ${.CURDIR}/../../fdt/help.fdt + cat ${.ALLSRC} | \ + awk -f ${.CURDIR}/../../common/merge_help.awk > ${.TARGET} + +ldscript.abs: + echo "UBLDR_LOADADDR =3D ${UBLDR_LOADADDR};" >${.TARGET} + +ldscript.pie: + echo "UBLDR_LOADADDR =3D 0;" >${.TARGET} + +ubldr: ${OBJS} ldscript.abs ${.CURDIR}/ldscript.${MACHINE_CPUARCH} = ${DPADD} + ${CC} ${CFLAGS} -T ldscript.abs ${LDFLAGS} \ + -o ${.TARGET} ${OBJS} ${LDADD} + +ubldr.pie: ${OBJS} ldscript.pie ${.CURDIR}/ldscript.${MACHINE_CPUARCH} = ${DPADD} + ${CC} ${CFLAGS} -T ldscript.pie ${LDFLAGS} -pie -Wl,-Bsymbolic \ + -o ${.TARGET} ${OBJS} ${LDADD} + +ubldr.bin: ubldr.pie + ${OBJCOPY} -S -O binary ubldr.pie ${.TARGET} + +CLEANFILES+=3D ldscript.abs ldscript.pie ubldr ubldr.pie ubldr.bin + +.if !defined(LOADER_ONLY) +.PATH: ${.CURDIR}/../../forth +.include "${.CURDIR}/../../forth/Makefile.inc" + +# Install loader.rc. +FILES+=3D loader.rc +# Put sample menu.rc on disk but don't enable it by default. +FILES+=3D menu.rc +FILESNAME_menu.rc=3D menu.rc.sample +.endif + +.include Property changes on: sys/boot/arm64/uboot/Makefile ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=3D%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: sys/boot/arm64/uboot/conf.c =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 --- sys/boot/arm64/uboot/conf.c (nonexistent) +++ sys/boot/arm64/uboot/conf.c (working copy) @@ -0,0 +1,94 @@ +/*- + * Copyright (c) 2008 Semihalf, Rafal Jaworowski + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in = the + * documentation and/or other materials provided with the = distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' = AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, = THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR = PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE = LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR = CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE = GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS = INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, = STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN = ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY = OF + * SUCH DAMAGE. + * + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include "bootstrap.h" +#include "libuboot.h" + +#if defined(LOADER_NET_SUPPORT) +#include "dev_net.h" +#endif + +struct devsw *devsw[] =3D { +#if defined(LOADER_DISK_SUPPORT) || defined(LOADER_CD9660_SUPPORT) + &uboot_storage, +#endif +#if defined(LOADER_NET_SUPPORT) + &netdev, +#endif + NULL +}; + +struct fs_ops *file_system[] =3D { +#if defined(LOADER_UFS_SUPPORT) + &ufs_fsops, +#endif +#if defined(LOADER_CD9660_SUPPORT) + &cd9660_fsops, +#endif +#if defined(LOADER_EXT2FS_SUPPORT) + &ext2fs_fsops, +#endif +#if defined(LOADER_NANDFS_SUPPORT) + &nandfs_fsops, +#endif +#if defined(LOADER_NFS_SUPPORT) + &nfs_fsops, +#endif +#if defined(LOADER_TFTP_SUPPORT) + &tftp_fsops, +#endif +#if defined(LOADER_GZIP_SUPPORT) + &gzipfs_fsops, +#endif +#if defined(LOADER_BZIP2_SUPPORT) + &bzipfs_fsops, +#endif + NULL +}; + +struct netif_driver *netif_drivers[] =3D { +#if defined(LOADER_NET_SUPPORT) + &uboot_net, +#endif + NULL, +}; + +struct file_format *file_formats[] =3D { + &uboot_elf, + NULL +}; + +extern struct console uboot_console; + +struct console *consoles[] =3D { + &uboot_console, + NULL +}; Property changes on: sys/boot/arm64/uboot/conf.c ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=3D%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: sys/boot/arm64/uboot/help.uboot =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 --- sys/boot/arm64/uboot/help.uboot (nonexistent) +++ sys/boot/arm64/uboot/help.uboot (working copy) @@ -0,0 +1,27 @@ +$FreeBSD$ + = +#########################################################################= ###### +# Tubenv DShow or import U-Boot environment variables + + ubenv [varname ...] + + Display U-Boot environment variables, or import them into the + loader environment (which makes them available in the kernel). + = +#########################################################################= ###### +# Tubenv Simport DImport U-Boot env vars + + ubenv import [varname ...] + + If no variable names are specified, all U-Boot environment + variables are imported. Each variable is prefixed with "uboot." + to avoid any possible conflicts with loader or kernel variables. + = +#########################################################################= ###### +# Tubenv Sshow DShow U-Boot env vars + + ubenv show [varname ...] + + If no variable names are specified, all U-Boot environment + variables are shown. + Index: sys/boot/arm64/uboot/ldscript.aarch64 =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 --- sys/boot/arm64/uboot/ldscript.aarch64 (nonexistent) +++ sys/boot/arm64/uboot/ldscript.aarch64 (working copy) @@ -0,0 +1,133 @@ +/* $FreeBSD$ */ + +OUTPUT_ARCH(aarch64) +ENTRY(_start) +SECTIONS +{ + /* Read-only sections, merged into text segment: */ + . =3D UBLDR_LOADADDR + SIZEOF_HEADERS; + .text : + { + *(.text) + /* .gnu.warning sections are handled specially by elf32.em. */ + *(.gnu.warning) + *(.gnu.linkonce.t*) + } =3D0 + _etext =3D .; + PROVIDE (etext =3D .); + .interp : { *(.interp) } + .hash : { *(.hash) } + .dynsym : { *(.dynsym) } + .dynstr : { *(.dynstr) } + .gnu.version : { *(.gnu.version) } + .gnu.version_d : { *(.gnu.version_d) } + .gnu.version_r : { *(.gnu.version_r) } + .rela.text : + { *(.rela.text) *(.rela.gnu.linkonce.t*) } + .rela.data : + { *(.rela.data) *(.rela.gnu.linkonce.d*) } + .rela.rodata : + { *(.rela.rodata) *(.rela.gnu.linkonce.r*) } + .rela.got : { *(.rela.got) } + .rela.got1 : { *(.rela.got1) } + .rela.got2 : { *(.rela.got2) } + .rela.ctors : { *(.rela.ctors) } + .rela.dtors : { *(.rela.dtors) } + .rela.init : { *(.rela.init) } + .rela.fini : { *(.rela.fini) } + .rela.bss : { *(.rela.bss) } + .rela.plt : { *(.rela.plt) } + .rela.sdata : { *(.rela.sdata) } + .rela.sbss : { *(.rela.sbss) } + .rela.sdata2 : { *(.rela.sdata2) } + .rela.sbss2 : { *(.rela.sbss2) } + .init : { *(.init) } =3D0 + .fini : { *(.fini) } =3D0 + .rodata : { *(.rodata) *(.gnu.linkonce.r*) } + .rodata1 : { *(.rodata1) } + .sdata2 : { *(.sdata2) } + .sbss2 : { *(.sbss2) } + /* Adjust the address for the data segment to the next page up. */ + . =3D ((. + 0x1000) & ~(0x1000 - 1)); + .data : + { + *(.data) + *(.gnu.linkonce.d*) + CONSTRUCTORS + } + .data1 : { *(.data1) } + .got1 : { *(.got1) } + .dynamic : { *(.dynamic) } + /* Put .ctors and .dtors next to the .got2 section, so that the = pointers + get relocated with -mrelocatable. Also put in the .fixup pointers. + The current compiler no longer needs this, but keep it around for = 2.7.2 */ + PROVIDE (_GOT2_START_ =3D .); + .got2 : { *(.got2) } + PROVIDE (__CTOR_LIST__ =3D .); + .ctors : { *(.ctors) } + PROVIDE (__CTOR_END__ =3D .); + PROVIDE (__DTOR_LIST__ =3D .); + .dtors : { *(.dtors) } + PROVIDE (__DTOR_END__ =3D .); + PROVIDE (_FIXUP_START_ =3D .); + .fixup : { *(.fixup) } + PROVIDE (_FIXUP_END_ =3D .); + PROVIDE (_GOT2_END_ =3D .); + PROVIDE (_GOT_START_ =3D .); + .got : { *(.got) } + .got.plt : { *(.got.plt) } + PROVIDE (_GOT_END_ =3D .); + /* We want the small data sections together, so single-instruction = offsets + can access them all, and initialized data all before = uninitialized, so + we can shorten the on-disk segment size. */ + .sdata : { *(.sdata) } + _edata =3D .; + PROVIDE (edata =3D .); + .sbss : + { + PROVIDE (__sbss_start =3D .); + *(.sbss) + *(.scommon) + *(.dynsbss) + PROVIDE (__sbss_end =3D .); + } + .plt : { *(.plt) } + .bss : + { + PROVIDE (__bss_start =3D .); + *(.dynbss) + *(.bss) + *(COMMON) + } + _end =3D . ; + PROVIDE (end =3D .); + /* Stabs debugging sections. */ + .stab 0 : { *(.stab) } + .stabstr 0 : { *(.stabstr) } + /* DWARF debug sections. + Symbols in the DWARF debugging sections are relative to the = beginning + of the section so we begin them at 0. */ + /* DWARF 1 */ + .debug 0 : { *(.debug) } + .line 0 : { *(.line) } + /* GNU DWARF 1 extensions */ + .debug_srcinfo 0 : { *(.debug_srcinfo) } + .debug_sfnames 0 : { *(.debug_sfnames) } + /* DWARF 1.1 and DWARF 2 */ + .debug_aranges 0 : { *(.debug_aranges) } + .debug_pubnames 0 : { *(.debug_pubnames) } + /* DWARF 2 */ + .debug_info 0 : { *(.debug_info) } + .debug_abbrev 0 : { *(.debug_abbrev) } + .debug_line 0 : { *(.debug_line) } + .debug_frame 0 : { *(.debug_frame) } + .debug_str 0 : { *(.debug_str) } + .debug_loc 0 : { *(.debug_loc) } + .debug_macinfo 0 : { *(.debug_macinfo) } + /* SGI/MIPS DWARF 2 extensions */ + .debug_weaknames 0 : { *(.debug_weaknames) } + .debug_funcnames 0 : { *(.debug_funcnames) } + .debug_typenames 0 : { *(.debug_typenames) } + .debug_varnames 0 : { *(.debug_varnames) } + /* These must appear regardless of . */ +} Index: sys/boot/arm64/uboot/loader.conf =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 --- sys/boot/arm64/uboot/loader.conf (nonexistent) +++ sys/boot/arm64/uboot/loader.conf (working copy) @@ -0,0 +1,13 @@ +# This is defaults/loader.conf for ARM 64, containing defaults for = loader(8). +# Do not modify the contents of this file, instead put your = customizations +# into /boot/loader.conf or /boot/loader.conf.local +# $FreeBSD$ + +autoboot_delay=3D10 +bootfile=3D"kernel" # Kernel name (possibly absolute path) +kernel=3D"kernel" # /boot sub-directory containing kernel and = modules +loader_conf_files=3D"/boot/loader.conf /boot/loader.conf.local" +module_path=3D"/boot/kernel;/boot/modules;/boot/dtb" +nextboot_conf=3D"/boot/nextboot.conf" +nextboot_enable=3D"NO" +verbose_loading=3D"NO" Property changes on: sys/boot/arm64/uboot/loader.conf ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=3D%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: sys/boot/arm64/uboot/start.S =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 --- sys/boot/arm64/uboot/start.S (nonexistent) +++ sys/boot/arm64/uboot/start.S (working copy) @@ -0,0 +1,122 @@ +/*- + * Copyright (c) 2008 Semihalf, Rafal Czubak + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in = the + * documentation and/or other materials provided with the = distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' = AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, = THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR = PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE = LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR = CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE = GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS = INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, = STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN = ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY = OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +#include + + .text + .extern _C_LABEL(self_reloc), _C_LABEL(main) + .weak _DYNAMIC + +/* + * Entry point to the loader that U-Boot passes control to. + */ + .globl _start +_start: + + /*=20 + * Do self-relocation when the weak external symbol _DYNAMIC is = non-NULL. + * When linked as a dynamic relocatable file, the linker = automatically + * defines _DYNAMIC with a value that is the offset of the = dynamic + * relocation info section. + * Note that we're still on u-boot's stack here, but the = self_reloc=20 + * code uses only a couple dozen bytes of stack space. + */ + ldr x15, =3D.here_off /* .here_off is a symbol = whose value */ + ldr x0, [x15] /* is its own offset in the text = seg. */ + sub x0, x15, x0 /* Get its pc-relative address = and */ + ldr x1, .dynamic_off /* subtract its value and we get = */ + cmp x1, #0 /* x0 =3D physaddr we were = loaded at. */ + b.eq 2f + add x1, x1, x0 /* x1 =3D dynamic section = physaddr. */ + bl _C_LABEL(self_reloc) /* Do reloc if _DYNAMIC is = non-NULL. */ +2:=09 + /* Hint where to look for the API signature */ + ldr x15, =3Duboot_address + mov x0, sp + str x0, [x15] + + /* Save U-Boot's x18 */ + ldr x15, =3Dsaved_regs + str x18, [x15, #0] + + /*=20 + * Start loader. This is basically a tail-recursion call; if = main() + * returns, it returns to u-boot (which reports the value = returned x0). + */ + b main + + /*=20 + * Data for self-relocation, in the text segment for pc-rel = access. + */ + .align 3 +.here_off: + .quad . +.dynamic_off: + .quad _DYNAMIC + +/* + * syscall() + */ +ENTRY(syscall) + /* Save caller's lr, x18 */ + ldr x15, =3Dsaved_regs + str x18, [x15, #8] + str lr, [x15, #16] +=09 + /* Restore U-Boot's x18 */ + ldr x18, saved_regs +=09 + /* Call into U-Boot */ + ldr lr, =3Dreturn_from_syscall + ldr x15, syscall_ptr + br x15 +return_from_syscall: + /* Restore loader's x18 and lr */ + ldr lr, saved_regs + 16 + ldr x18, saved_regs + 8 + /* Return to caller */ + ret + +/* + * Data section + */ + .data + .align 3 + .globl syscall_ptr +syscall_ptr: + .quad 0 + + .globl uboot_address +uboot_address: + .quad 0 + +saved_regs: + .quad 0 /* U-Boot's x18 */ + .quad 0 /* Loader's x18 */ + .quad 0 /* Loader's lr */ Property changes on: sys/boot/arm64/uboot/start.S ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=3D%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: sys/boot/arm64/uboot/version =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 --- sys/boot/arm64/uboot/version (nonexistent) +++ sys/boot/arm64/uboot/version (working copy) @@ -0,0 +1,9 @@ +$FreeBSD$ + +NOTE ANY CHANGES YOU MAKE TO THE BOOTBLOCKS HERE. The format of this +file is important. Make sure the current version number is on line 6. + +1.2: Extended with NAND FS support. +1.1: Flattened Device Tree blob support. +1.0: Added storage support. Booting from HDD, USB, etc. is now = possible. +0.5: Initial U-Boot/arm version (netbooting only). Index: sys/boot/common/load_elf.c =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 --- sys/boot/common/load_elf.c (revision 292987) +++ sys/boot/common/load_elf.c (working copy) @@ -198,7 +198,7 @@ * leave dest set to the value calculated by = archsw.arch_loadaddr() and * passed in to this function. */ -#ifndef __arm__ +#if !defined(__arm__) && !defined(__aarch64__) if (ehdr->e_type =3D=3D ET_EXEC) dest =3D (ehdr->e_entry & ~PAGE_MASK); #endif @@ -370,6 +370,24 @@ #ifdef ELF_VERBOSE printf("ehdr->e_entry 0x%08x, va<->pa off %llx\n", = ehdr->e_entry, off); #endif +#elif defined(__aarch64__) + /* + * The elf headers in arm kernels specify virtual addresses in = all + * header fields, even the ones that should be physical = addresses. + * We assume the entry point is in the first 2MB, and masking = the lower + * bits will leave us with the virtual address the kernel was = linked + * at. We subtract that from the load offset, making 'off' into = the + * value which, when added to a virtual address in an elf = header, + * translates it to a physical address. We do the va->pa = conversion on + * the entry point address in the header now, so that later we = can + * launch the kernel by just jumping to that address. + */ +#define KERN_ALIGN (2 * 1024 * 1024) /* XXX: where should this go? */ + off -=3D ehdr->e_entry & ~(KERN_ALIGN-1); + ehdr->e_entry +=3D off; +#ifdef ELF_VERBOSE + printf("ehdr->e_entry %p, va<->pa off 0x%llx\n", ehdr->e_entry, = off); +#endif #else off =3D 0; /* other archs use direct mapped kernels = */ #endif Index: sys/boot/efi/loader/bootinfo.c =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 --- sys/boot/efi/loader/bootinfo.c (revision 292987) +++ sys/boot/efi/loader/bootinfo.c (working copy) @@ -219,7 +219,7 @@ if (fp->f_args) MOD_ARGS(addr, fp->f_args, c); v =3D fp->f_addr; -#if defined(__arm__) +#if defined(__arm__) || defined(__aarch64__) v -=3D __elfN(relocation_offset); #endif MOD_ADDR(addr, v, c); @@ -350,7 +350,7 @@ vm_offset_t dtbp; int dtb_size; #endif -#if defined(__arm__) +#if defined(__arm__) || defined(__aarch64__) vm_offset_t vaddr; int i; /* @@ -439,7 +439,7 @@ md =3D file_findmetadata(kfp, MODINFOMD_KERNEND); bcopy(&kernend, md->md_data, sizeof kernend); =20 -#if defined(__arm__) +#if defined(__arm__) || defined(__aarch64__) *modulep -=3D __elfN(relocation_offset); =20 /* Do relocation fixup on metadata of each module. */ Index: sys/boot/uboot/common/main.c =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 --- sys/boot/uboot/common/main.c (revision 292987) +++ sys/boot/uboot/common/main.c (working copy) @@ -133,7 +133,7 @@ size =3D memsize(si, t[i]); if (size > 0) printf("%s: %lldMB\n", ub_mem_type(t[i]), - size / 1024 / 1024); + (unsigned long long)size / 1024 / 1024); } } =20 @@ -512,7 +512,7 @@ { =20 printf("heap base at %p, top at %p, used %d\n", end, sbrk(0), - sbrk(0) - end); + (int)(sbrk(0) - end)); =20 return (CMD_OK); } Index: sys/boot/uboot/fdt/Makefile =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 --- sys/boot/uboot/fdt/Makefile (revision 292987) +++ sys/boot/uboot/fdt/Makefile (working copy) @@ -24,7 +24,7 @@ CFLAGS+=3D -I${.CURDIR}/../../common -I${.CURDIR}/../../.. -I. =20 machine: - ln -sf ${.CURDIR}/../../../${MACHINE_CPUARCH}/include machine + ln -sf ${.CURDIR}/../../../${MACHINE}/include machine =20 CLEANFILES+=3D machine =20 Index: sys/boot/uboot/lib/Makefile =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 --- sys/boot/uboot/lib/Makefile (revision 292987) +++ sys/boot/uboot/lib/Makefile (working copy) @@ -42,7 +42,7 @@ .endif =20 machine: - ln -sf ${.CURDIR}/../../../${MACHINE_CPUARCH}/include machine + ln -sf ${.CURDIR}/../../../${MACHINE}/include machine =20 CLEANFILES+=3D machine =20 Index: sys/boot/uboot/lib/copy.c =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 --- sys/boot/uboot/lib/copy.c (revision 292987) +++ sys/boot/uboot/lib/copy.c (working copy) @@ -40,7 +40,7 @@ * MD primitives supporting placement of module data=20 */ =20 -#ifdef __arm__ +#if defined(__arm__) || defined(__aarch64__) #define KERN_ALIGN (2 * 1024 * 1024) #else #define KERN_ALIGN PAGE_SIZE Index: sys/boot/uboot/lib/disk.c =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 --- sys/boot/uboot/lib/disk.c (revision 292987) +++ sys/boot/uboot/lib/disk.c (working copy) @@ -156,8 +156,8 @@ } =20 if (size % SI(dev).bsize) { - stor_printf("size=3D%d not multiple of device block = size=3D%d\n", - size, SI(dev).bsize); + stor_printf("size=3D%ld not multiple of device block = size=3D%d\n", + (long)size, SI(dev).bsize); return (EIO); } bcount =3D size / SI(dev).bsize; Index: sys/boot/uboot/lib/elf_freebsd.c =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 --- sys/boot/uboot/lib/elf_freebsd.c (revision 292987) +++ sys/boot/uboot/lib/elf_freebsd.c (working copy) @@ -81,7 +81,7 @@ return (error); =20 entry =3D (void *)e->e_entry; - printf("Kernel entry at 0x%x...\n", (unsigned)entry); + printf("Kernel entry at 0x%p...\n", entry); =20 dev_cleanup(); printf("Kernel args: %s\n", fp->f_args); Index: sys/boot/uboot/lib/glue.c =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 --- sys/boot/uboot/lib/glue.c (revision 292987) +++ sys/boot/uboot/lib/glue.c (working copy) @@ -109,7 +109,7 @@ { int c; =20 - if (!syscall(API_GETC, NULL, (uint32_t)&c)) + if (!syscall(API_GETC, NULL, (uintptr_t)&c)) return (-1); =20 return (c); @@ -120,7 +120,7 @@ { int t; =20 - if (!syscall(API_TSTC, NULL, (uint32_t)&t)) + if (!syscall(API_TSTC, NULL, (uintptr_t)&t)) return (-1); =20 return (t); @@ -130,7 +130,7 @@ ub_putc(char c) { =20 - syscall(API_PUTC, NULL, (uint32_t)&c); + syscall(API_PUTC, NULL, (uintptr_t)&c); } =20 void @@ -137,7 +137,7 @@ ub_puts(const char *s) { =20 - syscall(API_PUTS, NULL, (uint32_t)s); + syscall(API_PUTS, NULL, (uintptr_t)s); } =20 /**************************************** @@ -166,7 +166,7 @@ si.mr_no =3D UB_MAX_MR; memset(&mr, 0, sizeof(mr)); =20 - if (!syscall(API_GET_SYS_INFO, &err, (u_int32_t)&si)) + if (!syscall(API_GET_SYS_INFO, &err, (uintptr_t)&si)) return (NULL); =20 return ((err) ? NULL : &si); @@ -483,7 +483,7 @@ { char *value; =20 - if (!syscall(API_ENV_GET, NULL, (uint32_t)name, = (uint32_t)&value)) + if (!syscall(API_ENV_GET, NULL, (uintptr_t)name, = (uintptr_t)&value)) return (NULL); =20 return (value); @@ -493,7 +493,7 @@ ub_env_set(const char *name, char *value) { =20 - syscall(API_ENV_SET, NULL, (uint32_t)name, (uint32_t)value); + syscall(API_ENV_SET, NULL, (uintptr_t)name, (uintptr_t)value); } =20 static char env_name[256]; @@ -510,7 +510,7 @@ * internally, which handles such case */ env =3D NULL; - if (!syscall(API_ENV_ENUM, NULL, (uint32_t)last, = (uint32_t)&env)) + if (!syscall(API_ENV_ENUM, NULL, (uintptr_t)last, = (uintptr_t)&env)) return (NULL); =20 if (env =3D=3D NULL || last =3D=3D env) --Apple-Mail=_F075A616-44A9-4C1F-98E9-03F8A745328B-- From owner-freebsd-arm@freebsd.org Fri Jan 1 02:00:18 2016 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 BEEA2A562C4 for ; Fri, 1 Jan 2016 02:00:18 +0000 (UTC) (envelope-from sig6247@openmailbox.org) Received: from mail2.openmailbox.org (mail2.openmailbox.org [62.4.1.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 812B61FC4 for ; Fri, 1 Jan 2016 02:00:18 +0000 (UTC) (envelope-from sig6247@openmailbox.org) Received: by mail2.openmailbox.org (Postfix, from userid 1004) id 80CBA2AC3D8C; Fri, 1 Jan 2016 03:00:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1451613609; bh=ymc7SpMhmpj2KN62EGQAVBnF1+f+hogTW+EdGQO0wPk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=smhcDda6gqURF2QVeJCend+4QkJWMvPMmBGoGITx5E9ouv5/pWeis6sIc6JRPU/KB Y69564ys/p7/OZnIsx3CuOSuLpP5DLn/lnWl5je5gqwDYzzJ6EdCdvwq4YKJX4auyj hN48BwZEJdASMDw+eQpPJeXnHKCCYMQ7ZOL0sdLc= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on openmailbox-b2 X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MISSING_MID,NO_RECEIVED,NO_RELAYS autolearn=no autolearn_force=no version=3.4.0 Date: Fri, 01 Jan 2016 01:59:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1451613606; bh=ymc7SpMhmpj2KN62EGQAVBnF1+f+hogTW+EdGQO0wPk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ju1tznK46fa24yeEEXT99LSpzc7nu+29At0oItaOoarlVVAfg6qGKAKWO3JZ+sdxt gNo40NVx81s1On+7+nx1FNJOyq2rDCULITs2Yv5Mo7xa8LKQdCElK27FOXgWca8cAZ q2UDLC5muOvRx7wzoWbhayya4oDVE9FupdZbLFs0= From: sig6247 To: Ganbold Tsagaankhuu Cc: freebsd-arm Subject: Re: emac0 not working on BananaPi M1 In-Reply-To: (Ganbold Tsagaankhuu's message of "Tue, 29 Dec 2015 21:30:09 +0800") References: <20151229110117.AB6447C2D5E@mail2.openmailbox.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20160101020009.80CBA2AC3D8C@mail2.openmailbox.org> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 02:00:18 -0000 On Tue, 29 Dec 2015 21:30:09 +0800, Ganbold Tsagaankhuu wrote: > On Tue, Dec 29, 2015 at 7:00 PM, sig6247 wrote: > >> >> Hi, >> >> I'm running 11.0-CURRENT r291838 on a BananaPi M1, emac0 never worked >> for me, so I have to use a wireless adaper all the time. >> > > bananapi1 has gmac too, so you should really use if_dwc. Thanks so much. I had no idea conf/A20 had updated and replaced emac with dwc, was still compiling with an old kernel config, my bad. dwc0 works great. From owner-freebsd-arm@freebsd.org Fri Jan 1 12:32:13 2016 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 5EA33A5697B for ; Fri, 1 Jan 2016 12:32:13 +0000 (UTC) (envelope-from sjms@dicave.org) Received: from sm-srv.dicave.org (sm-srv.dicave.org [94.140.215.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Sergey Chvertnyak", Issuer "Sergey Chvertnyak" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CD1931A3A; Fri, 1 Jan 2016 12:32:12 +0000 (UTC) (envelope-from sjms@dicave.org) Received: from [192.168.20.17] ([192.168.20.17]) (authenticated bits=0) by sm-srv.dicave.org (8.15.2/8.15.2) with ESMTPSA id u01CVfL7064116 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 1 Jan 2016 15:32:03 +0300 (MSK) (envelope-from sjms@dicave.org) From: Sergey Chvertnyak Subject: Re: support Allwinner H3 To: freebsd-arm@freebsd.org, kevlo@freebsd.org, raycherng@gmail.com References: Message-ID: <568671A8.4010007@dicave.org> Date: Fri, 1 Jan 2016 15:31:36 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 12:32:13 -0000 I ordered another OrangePi PC and it works the same way as the first motherboard. Yes, there were problems with Linux distributions, namely the LAN adapter (http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=471) - is a software error. The product itself, I find promising, namely OrangePi PC (http://ru.aliexpress.com/item/Orange-Pi-PC-linux-and-android-mini-PC-Beyond-Raspberry-Pi-2/32448079125.html?detailNewVersion=2) This is not advertising, but matching the price and features. I need help with a bootloader to FreeBSDon OrangePi PC. Thanks. On 15.12.2015 15:00, freebsd-arm-request@freebsd.org wrote: > Message: 1 > Date: Mon, 14 Dec 2015 20:26:25 +0800 > From: RayCherng Yu > To: Kevin Lo > Cc: ?????? ???????? , freebsd-arm@freebsd.org > Subject: Re: support Allwinner H3 > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > I have one Orange Pi PC. Kevlo bought for me . We receive two Orange Pi PC > board. They look the same but run different.... > Kevlo use the official linux image and it runs well. My Orange Pi PC can't > run the official linux image but my board runs the image that loboris built > [1] very well. Kevlo's board can't run loboris's image~~ > > Who want to port FreeBSD to this kind of board? You don't know which board > can run, which board can't. > > So our Orange Pi PC look the same but they are just similiar... > > I think I won't buy any product made by this company > > [1] http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=342 > > > 2015-12-11 23:00 GMT+08:00 Kevin Lo : > >> On Fri, Dec 11, 2015 at 01:00:32AM +0300, ?????? ???????? wrote: >>> Please help. >>> I do not understand how to create a boot exactly for Allwinner H3 (board >> OrangePi >>> PC). >>> There are practices in support of processors Allwinner H3? >> Thanks to Ganbold who added support for Allwinner A10/A20 SoCs, >> porting to H3 is straightforward. I have a preliminary patch for this, >> but I don't want to continue working on it. It seems there's a hardware >> issue with Orange Pi PC [1]. I had a similar issue with my Orange Pi PC >> when I used the images from Orange Pi download [2], it turned out that only >> Lubuntu image worked. >> >> [1] >> http://www.cnx-software.com/2015/10/02/orange-pi-pc-not-booting-you-are-not-alone/ >> [2] http://www.orangepi.org/downloadresources/ >> >>> Thanks! >>> >>> Best regards, Sergey! >> Kevin >> _______________________________________________ >> 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 Jan 1 14:31:25 2016 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 8427CA5EA6B for ; Fri, 1 Jan 2016 14:31:25 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1BF2C10A7 for ; Fri, 1 Jan 2016 14:31:24 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.14.9/8.14.9) with ESMTP id u01EUX7L069743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Jan 2016 22:30:34 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.14.9/8.14.9/Submit) id u01EUWnY069742; Fri, 1 Jan 2016 22:30:32 +0800 (CST) (envelope-from kevlo) Date: Fri, 1 Jan 2016 22:30:32 +0800 From: Kevin Lo To: Sergey Chvertnyak Cc: freebsd-arm@freebsd.org, raycherng@gmail.com Subject: Re: support Allwinner H3 Message-ID: <20160101143032.GA69730@ns.kevlo.org> References: <568671A8.4010007@dicave.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <568671A8.4010007@dicave.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 14:31:25 -0000 On Fri, Jan 01, 2016 at 03:31:36PM +0300, Sergey Chvertnyak wrote: > > I ordered another OrangePi PC and it works the same way as the first > motherboard. You're lucky. :) > Yes, there were problems with Linux distributions, namely the LAN adapter > (http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=471) > - is a software error. No. I'm pretty it's a hardware issue on my board. > The product itself, I find promising, namely OrangePi PC > (http://ru.aliexpress.com/item/Orange-Pi-PC-linux-and-android-mini-PC-Beyond-Raspberry-Pi-2/32448079125.html?detailNewVersion=2) > This is not advertising, but matching the price and features. > I need help with a bootloader to FreeBSDon OrangePi PC. Thanks. We need developers, not cheap as chips hardware. > On 15.12.2015 15:00, freebsd-arm-request@freebsd.org wrote: > > > Message: 1 > > Date: Mon, 14 Dec 2015 20:26:25 +0800 > > From: RayCherng Yu > > To: Kevin Lo > > Cc: ?????? ???????? , freebsd-arm@freebsd.org > > Subject: Re: support Allwinner H3 > > Message-ID: > > > > Content-Type: text/plain; charset=UTF-8 > > > > I have one Orange Pi PC. Kevlo bought for me . We receive two Orange Pi PC > > board. They look the same but run different.... > > Kevlo use the official linux image and it runs well. My Orange Pi PC can't > > run the official linux image but my board runs the image that loboris built > > [1] very well. Kevlo's board can't run loboris's image~~ > > > > Who want to port FreeBSD to this kind of board? You don't know which board > > can run, which board can't. > > > > So our Orange Pi PC look the same but they are just similiar... > > > > I think I won't buy any product made by this company > > > > [1] http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=342 > > > > > > 2015-12-11 23:00 GMT+08:00 Kevin Lo : > > > >> On Fri, Dec 11, 2015 at 01:00:32AM +0300, ?????? ???????? wrote: > >>> Please help. > >>> I do not understand how to create a boot exactly for Allwinner H3 (board > >> OrangePi > >>> PC). > >>> There are practices in support of processors Allwinner H3? > >> Thanks to Ganbold who added support for Allwinner A10/A20 SoCs, > >> porting to H3 is straightforward. I have a preliminary patch for this, > >> but I don't want to continue working on it. It seems there's a hardware > >> issue with Orange Pi PC [1]. I had a similar issue with my Orange Pi PC > >> when I used the images from Orange Pi download [2], it turned out that only > >> Lubuntu image worked. > >> > >> [1] > >> http://www.cnx-software.com/2015/10/02/orange-pi-pc-not-booting-you-are-not-alone/ > >> [2] http://www.orangepi.org/downloadresources/ > >> > >>> Thanks! > >>> > >>> Best regards, Sergey! > >> Kevin > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > >> > > > > > > From owner-freebsd-arm@freebsd.org Sat Jan 2 18:56:21 2016 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 D471AA5E0DA for ; Sat, 2 Jan 2016 18:56:21 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B7DDE19F3; Sat, 2 Jan 2016 18:56:21 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id DCF7218CF; Sat, 2 Jan 2016 18:56:21 +0000 (UTC) Date: Sat, 2 Jan 2016 18:56:19 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: adrian@FreeBSD.org, des@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <2059498175.89.1451760981872.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #2034 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2016 18:56:21 -0000 FreeBSD_HEAD_arm64 - Build #2034 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2034/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2034/ch= anges Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2034/con= sole Change summaries: 293050 by adrian: [ath] add explicit bus barriers. The ath hal and driver code all assume the world is an x86 or the bus layer does an explicit bus flush after each operation (eg netbsd.) However, we don't do that. So, to be "correct" on platforms like sparc64, mips and ppc (and maybe ARM, I am not sure), just do explicit barriers after each operation. Now, this does slow things down a tad on embedded platforms but I'd rather things be "correct" versus "fast." At some later point if someone wishes it to be fast then we should add the barrier calls to the HAL and driver. Tested: * carambola 2 (AR9331.) 293049 by des: Replace the cosine table with a sine table, which (due to the vagaries of rounding) has better spread. Implement fp16_sin() to go along with fp16_cos(). In the rendering loop, switch from addition to subtraction so the center of the pattern will be a trough rather than a peak. This is completely arbitrary, of course, but looks better to me. The end of the build log: [...truncated 171397 lines...] --- aic7xxx.o --- ctfconvert -L VERSION -g aic7xxx.o --- ahc.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o ahc.kld aic7xxx_= reg_print.o aic7xxx.o aic7xxx_93cx6.o aic7xxx_osm.o aic7770.o ctfmerge -L VERSION -g -o ahc.kld aic7xxx_reg_print.o aic7xxx.o aic7xxx_93c= x6.o aic7xxx_osm.o aic7770.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk ahc.kld export_syms | xargs -J% /us= r/local/aarch64-freebsd/bin/objcopy % ahc.kld --- ahc.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o ahc.ko.ful= l aic7xxx_reg_print.o aic7xxx.o aic7xxx_93cx6.o aic7xxx_osm.o aic7770.o --- ahc.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug ahc.ko.full ahc.ko= .debug --- ahc.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=3D= ahc.ko.debug ahc.ko.full ahc.ko --- dsargs.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/= src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADER= S -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-point= er -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector= -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -W= missing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-point= er-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagno= stics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -W= no-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-func= tion -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=3Diso= 9899:1999 -Werror /usr/src/sys/contrib/dev/acpica/components/dispatcher/ds= args.c ctfconvert -L VERSION -g dsargs.o --- modules-all --- --- all_subdir_alq --- =3D=3D=3D> alq (all) --- kern_alq.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werro= r -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys = -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgenera= l-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 = -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-pro= totypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D_= _printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-= option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-em= pty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-= error-pointer-sign -Wno-error-shift-negative-value -std=3Diso9899:1999 -= c /usr/src/sys/modules/alq/../../kern/kern_alq.c -o kern_alq.o ctfconvert -L VERSION -g kern_alq.o --- alq.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o alq.kld kern_alq= .o ctfmerge -L VERSION -g -o alq.kld kern_alq.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk alq.kld export_syms | xargs -J% /us= r/local/aarch64-freebsd/bin/objcopy % alq.kld --- alq.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o alq.ko.ful= l kern_alq.o --- alq.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug alq.ko.full alq.ko= .debug --- alq.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=3D= alq.ko.debug alq.ko.full alq.ko --- dscontrol.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/= src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADER= S -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-point= er -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector= -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -W= missing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-point= er-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagno= stics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -W= no-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-func= tion -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=3Diso= 9899:1999 -Werror /usr/src/sys/contrib/dev/acpica/components/dispatcher/ds= control.c --- modules-all --- --- all_subdir_ale --- ctfconvert -L VERSION -g if_ale.o --- if_ale.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o if_ale.kld if_al= e.o ctfmerge -L VERSION -g -o if_ale.kld if_ale.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk if_ale.kld export_syms | xargs -J% = /usr/local/aarch64-freebsd/bin/objcopy % if_ale.kld --- if_ale.ko.full --- --- dscontrol.o --- ctfconvert -L VERSION -g dscontrol.o --- modules-all --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o if_ale.ko.= full if_ale.o --- all_subdir_amr --- =3D=3D=3D> amr (all) --- all_subdir_ale --- --- if_ale.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug if_ale.ko.full if_= ale.ko.debug --- if_ale.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=3D= if_ale.ko.debug if_ale.ko.full if_ale.ko --- dsdebug.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/= src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADER= S -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-point= er -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector= -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -W= missing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-point= er-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagno= stics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -W= no-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-func= tion -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=3Diso= 9899:1999 -Werror /usr/src/sys/contrib/dev/acpica/components/dispatcher/ds= debug.c --- modules-all --- --- all_subdir_amr --- --- all_subdir_amr_cam --- =3D=3D=3D> amr/amr_cam (all) --- amr_cam.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werro= r -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys = -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgenera= l-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 = -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-pro= totypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D_= _printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-= option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-em= pty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-= error-pointer-sign -Wno-error-shift-negative-value -std=3Diso9899:1999 -= c /usr/src/sys/modules/amr/amr_cam/../../../dev/amr/amr_cam.c -o amr_cam.o --- dsdebug.o --- ctfconvert -L VERSION -g dsdebug.o --- modules-all --- --- amr_disk.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werro= r -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys = -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgenera= l-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 = -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-pro= totypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D_= _printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-= option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-em= pty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-= error-pointer-sign -Wno-error-shift-negative-value -std=3Diso9899:1999 -= c /usr/src/sys/modules/amr/../../dev/amr/amr_disk.c -o amr_disk.o ctfconvert -L VERSION -g amr_disk.o --- all_subdir_ata --- =3D=3D=3D> ata (all) --- all_subdir_atacore --- =3D=3D=3D> ata/atacore (all) --- all_subdir_amr --- --- all_subdir_amr_cam --- ctfconvert -L VERSION -g amr_cam.o --- all_subdir_ata --- --- ata-all.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werro= r -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys = -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgenera= l-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 = -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-pro= totypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D_= _printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-= option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-em= pty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-= error-pointer-sign -Wno-error-shift-negative-value -std=3Diso9899:1999 -= c /usr/src/sys/modules/ata/atacore/../../../dev/ata/ata-all.c -o ata-all.o --- all_subdir_amr --- --- amr_cam.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o amr_cam.kld amr_= cam.o ctfmerge -L VERSION -g -o amr_cam.kld amr_cam.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk amr_cam.kld export_syms | xargs -J%= /usr/local/aarch64-freebsd/bin/objcopy % amr_cam.kld --- amr_cam.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o amr_cam.ko= .full amr_cam.o --- amr_cam.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug amr_cam.ko.full am= r_cam.ko.debug --- amr_cam.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=3D= amr_cam.ko.debug amr_cam.ko.full amr_cam.ko --- amr.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werro= r -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys = -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgenera= l-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 = -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-pro= totypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D_= _printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-= option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-em= pty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-= error-pointer-sign -Wno-error-shift-negative-value -std=3Diso9899:1999 -= c /usr/src/sys/modules/amr/../../dev/amr/amr.c -o amr.o --- all_subdir_alc --- ctfconvert -L VERSION -g if_alc.o --- if_alc.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o if_alc.kld if_al= c.o --- all_subdir_aic7xxx --- --- all_subdir_ahd --- --- aic79xx.o --- ctfconvert -L VERSION -g aic79xx.o --- all_subdir_alc --- ctfmerge -L VERSION -g -o if_alc.kld if_alc.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk if_alc.kld export_syms | xargs -J% = /usr/local/aarch64-freebsd/bin/objcopy % if_alc.kld --- if_alc.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o if_alc.ko.= full if_alc.o --- if_alc.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug if_alc.ko.full if_= alc.ko.debug --- if_alc.ko --- --- all_subdir_aic7xxx --- --- ahd.kld --- --- all_subdir_alc --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=3D= if_alc.ko.debug if_alc.ko.full if_alc.ko --- all_subdir_aic7xxx --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o ahd.kld aic79xx_= reg_print.o aic79xx.o aic79xx_osm.o aic79xx_pci.o ahd_pci.o --- all_subdir_ata --- --- ata_if.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werro= r -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys = -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgenera= l-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 = -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-pro= totypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D_= _printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-= option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-em= pty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-= error-pointer-sign -Wno-error-shift-negative-value -std=3Diso9899:1999 -= c ata_if.c -o ata_if.o --- all_subdir_aic7xxx --- ctfmerge -L VERSION -g -o ahd.kld aic79xx_reg_print.o aic79xx.o aic79xx_osm= .o aic79xx_pci.o ahd_pci.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk ahd.kld export_syms | xargs -J% /us= r/local/aarch64-freebsd/bin/objcopy % ahd.kld --- ahd.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o ahd.ko.ful= l aic79xx_reg_print.o aic79xx.o aic79xx_osm.o aic79xx_pci.o ahd_pci.o --- ahd.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug ahd.ko.full ahd.ko= .debug --- ahd.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=3D= ahd.ko.debug ahd.ko.full ahd.ko --- all_subdir_ata --- ctfconvert -L VERSION -g ata_if.o --- all_subdir_ath --- --- all_subdir_ata --- --- all_subdir_atacard --- =3D=3D=3D> ata/atacard (all) --- all_subdir_ath --- =3D=3D=3D> ath (all) --- all_subdir_ata --- --- ata-card.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werro= r -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys = -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgenera= l-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 = -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-pro= totypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D_= _printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-= option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-em= pty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-= error-pointer-sign -Wno-error-shift-negative-value -std=3Diso9899:1999 -= c /usr/src/sys/modules/ata/atacard/../../../dev/ata/ata-card.c -o ata-card.= o --- all_subdir_ath --- --- ah.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werro= r -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/usr/src/sys/modules/ath/../../de= v/ath -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -I. -I/usr/src/sys/m= odules/ath/../../contrib/dev/ath/ath_hal/ -DHAVE_KERNEL_OPTION_HEADERS -inc= lude /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src= /sys -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mg= eneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwa= rf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissin= g-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sig= n -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-= show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-err= or-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function = -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=3Diso9899:1= 999 -c /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c -o ah.o /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:244:8: error: expected = expression if ((OS_REG_READ(ah, reg) & mask) =3D=3D val) ^ /usr/src/sys/modules/ath/../../dev/ath/ah_osdep.h:153:2: note: expanded fro= m macro 'OS_REG_READ' do { \ ^ /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:865:12: error: expected= expression *dp++ =3D OS_REG_READ(ah, r); ^ /usr/src/sys/modules/ath/../../dev/ath/ah_osdep.h:153:2: note: expanded fro= m macro 'OS_REG_READ' do { \ ^ /usr/src/sys/modules/ath/../../dev/ath/ath_hal/ah.c:1376:31: error: expecte= d expression OS_REG_WRITE(ah, AR_TSF_L32, OS_REG_READ(ah, AR_TSF_L32) + tsfdelta= ); ^ /usr/src/sys/modules/ath/../../dev/ath/ah_osdep.h:153:2: note: expanded fro= m macro 'OS_REG_READ' do { \ ^ /usr/src/sys/modules/ath/../../dev/ath/ah_osdep.h:149:49: note: expanded fr= om macro 'OS_REG_WRITE' (bus_space_handle_t)(_ah)->ah_sh, (_reg), (_val)); \ ^ ./machine/bus.h:376:62: note: expanded from macro 'bus_space_write_4' #define bus_space_write_4(t, h, o, v) __bs_ws(4,(t),(h),(o),(v)) ^ ./machine/bus.h:269:50: note: expanded from macro '__bs_ws' (*(t)->__bs_opname(w,sz))((t)->bs_cookie, h, o, v) ^ 3 errors generated. *** [ah.o] Error code 1 make[4]: stopped in /usr/src/sys/modules/ath 1 error make[4]: stopped in /usr/src/sys/modules/ath *** [all_subdir_ath] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_ata --- ctfconvert -L VERSION -g ata-card.o A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/sys/modules/ata/atacard *** [all_subdir_atacard] Error code 2 make[4]: stopped in /usr/src/sys/modules/ata --- all_subdir_atacore --- --- ata-all.o --- ctfconvert -L VERSION -g ata-all.o A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/sys/modules/ata/atacore *** [all_subdir_atacore] Error code 2 make[4]: stopped in /usr/src/sys/modules/ata 2 errors make[4]: stopped in /usr/src/sys/modules/ata *** [all_subdir_ata] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_amr --- ctfconvert -L VERSION -g amr.o A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/amr *** [all_subdir_amr] Error code 2 make[3]: stopped in /usr/src/sys/modules 3 errors make[3]: stopped in /usr/src/sys/modules *** [modules-all] Error code 2 make[2]: stopped in /usr/obj/arm64.aarch64/usr/src/sys/GENERIC 1 error make[2]: stopped in /usr/obj/arm64.aarch64/usr/src/sys/GENERIC *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson2797029572007804691.sh + export 'PATH=3D/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/b= in' + export 'jname=3DFreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::104:1 -alias + sudo umount FreeBSD_HEAD_arm64/usr/src + sudo umount FreeBSD_HEAD_arm64/dev + sudo rm -fr FreeBSD_HEAD_arm64 + true + sudo chflags -R noschg FreeBSD_HEAD_arm64 + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Sat Jan 2 21:00:02 2016 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 768DAA5EAF4 for ; Sat, 2 Jan 2016 21:00:02 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 687E31255; Sat, 2 Jan 2016 21:00:02 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 32036190F; Sat, 2 Jan 2016 21:00:02 +0000 (UTC) Date: Sat, 2 Jan 2016 21:00:00 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: nwhitehorn@FreeBSD.org, adrian@FreeBSD.org, ian@FreeBSD.org, emaste@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1014471237.93.1451768402177.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2059498175.89.1451760981872.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2059498175.89.1451760981872.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #2035 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2016 21:00:02 -0000 FreeBSD_HEAD_arm64 - Build #2035 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2035/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2035/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2035/console Change summaries: 293058 by nwhitehorn: Bump the maximum number of interrupt controllers to allow for the proliferation of them on large IBM systems and add some error checking if we exceed that number. MFC after: 1 week 293057 by nwhitehorn: Make using the #address-cells property on the interrupt parent in device tree parsing opt-out rather than opt-in. All FDT-based systems as well as PowerPC systems with real Open Firmware use the CHRP-derived binding that includes it, which makes SPARC the odd man out here. Making it opt-out avoids astonishment on new platform bring up. 293056 by ian: Add an OF_decode_addr() implementation for arm64. Discussed with: andrew 293055 by emaste: kbdmap.5: Use current names for ASCII control codes lf, ff, us Refer to the old names nl, np, ns as historical aliases. PR: 205776, 205778 MFC After: 1 week Sponsored by: The FreeBSD Foundation 293054 by adrian: ... and that would've never worked. Sorry! (Note: everything I tested on locally has ATH_DEBUG / AH_DEBUG set.) 293053 by ian: Use 64-bit math when finding a block of ram to hold the kernel. This fixes a problem on 32-bit systems which have ram occupying the end of the physical address space -- for example, a block of ram at 0x80000000 with a size of 0x80000000 was overflowing 32 bit math and ending up with a calculated size of zero. This is a fix for one of the two problems mentioned in the PR. Something similar will need to be done on the kernel side before the PR is closed. PR: 201614 293052 by nwhitehorn: Bring CPU features list in line with the ABI requirements. MFC after: 1 week 293051 by nwhitehorn: Switch setting MSR[SF] to C code. This removes any CPU-specific code (MSF[SF] is a Book 3-S thing) in the 64-bit locore64.S. The end of the build log: [...truncated 189186 lines...] ctfconvert -L VERSION -g randomdev.o --- xhci.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/controller/xhci.c --- cam_xpt.o --- ctfconvert -L VERSION -g cam_xpt.o --- usb_busdma.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_busdma.c --- ahci.o --- ctfconvert -L VERSION -g ahci.o --- usb_core.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_core.c ctfconvert -L VERSION -g usb_core.o --- usb_debug.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_debug.c --- usb_busdma.o --- ctfconvert -L VERSION -g usb_busdma.o --- usb_dynamic.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_dynamic.c --- usb_debug.o --- ctfconvert -L VERSION -g usb_debug.o --- usb_error.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_error.c --- usb_dynamic.o --- ctfconvert -L VERSION -g usb_dynamic.o --- usb_generic.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_generic.c --- usb_error.o --- ctfconvert -L VERSION -g usb_error.o --- usb_hid.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_hid.c ctfconvert -L VERSION -g usb_hid.o --- usb_hub.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_hub.c --- xhci.o --- ctfconvert -L VERSION -g xhci.o --- usb_lookup.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_lookup.c --- usb_generic.o --- ctfconvert -L VERSION -g usb_generic.o --- dwc_otg.o --- ctfconvert -L VERSION -g dwc_otg.o --- usb_mbuf.o --- --- usb_msctest.o --- --- usb_mbuf.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_mbuf.c --- usb_msctest.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_msctest.c --- usb_lookup.o --- ctfconvert -L VERSION -g usb_lookup.o --- usb_parse.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_parse.c --- usb_mbuf.o --- ctfconvert -L VERSION -g usb_mbuf.o --- usb_pf.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_pf.c --- usb_parse.o --- ctfconvert -L VERSION -g usb_parse.o --- usb_process.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_process.c --- usb_msctest.o --- ctfconvert -L VERSION -g usb_msctest.o --- usb_request.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_request.c --- usb_process.o --- ctfconvert -L VERSION -g usb_process.o --- usb_transfer.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_transfer.c --- usb_pf.o --- ctfconvert -L VERSION -g usb_pf.o --- usb_util.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/usb_util.c --- usb_hub.o --- ctfconvert -L VERSION -g usb_hub.o --- ukbd.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/usb/input/ukbd.c --- usb_util.o --- ctfconvert -L VERSION -g usb_util.o --- if_vtnet.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/virtio/network/if_vtnet.c --- usb_request.o --- ctfconvert -L VERSION -g usb_request.o --- virtio_blk.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/virtio/block/virtio_blk.c --- ukbd.o --- ctfconvert -L VERSION -g ukbd.o --- watchdog.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/dev/watchdog/watchdog.c --- usb_transfer.o --- ctfconvert -L VERSION -g usb_transfer.o --- geom_dev.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/geom/geom_dev.c --- virtio_blk.o --- ctfconvert -L VERSION -g virtio_blk.o --- watchdog.o --- ctfconvert -L VERSION -g watchdog.o --- kern_clock.o --- --- kern_cpuset.o --- --- kern_clock.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_clock.c --- kern_cpuset.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_cpuset.c --- geom_dev.o --- ctfconvert -L VERSION -g geom_dev.o --- kern_ffclock.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_ffclock.c --- kern_clock.o --- ctfconvert -L VERSION -g kern_clock.o WARNING: kern_clock.c: enum pmc_event has too many values: 2588 > 1023 --- kern_intr.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_intr.c --- kern_ffclock.o --- ctfconvert -L VERSION -g kern_ffclock.o --- kern_mutex.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_mutex.c --- if_vtnet.o --- ctfconvert -L VERSION -g if_vtnet.o --- kern_numa.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_numa.c --- kern_cpuset.o --- ctfconvert -L VERSION -g kern_cpuset.o --- kern_rctl.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_rctl.c --- kern_numa.o --- ctfconvert -L VERSION -g kern_numa.o --- kern_timeout.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/kern_timeout.c --- kern_intr.o --- ctfconvert -L VERSION -g kern_intr.o --- subr_bus.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/subr_bus.c --- kern_mutex.o --- ctfconvert -L VERSION -g kern_mutex.o WARNING: kern_mutex.c: enum pmc_event has too many values: 2588 > 1023 --- subr_bus_dma.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/subr_bus_dma.c ctfconvert -L VERSION -g subr_bus_dma.o --- subr_clock.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/subr_clock.c --- kern_timeout.o --- ctfconvert -L VERSION -g kern_timeout.o --- subr_hints.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/subr_hints.c --- kern_rctl.o --- ctfconvert -L VERSION -g kern_rctl.o --- subr_rman.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/subr_rman.c --- subr_clock.o --- ctfconvert -L VERSION -g subr_clock.o --- subr_rtc.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/subr_rtc.c --- subr_hints.o --- ctfconvert -L VERSION -g subr_hints.o --- subr_smp.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/subr_smp.c --- subr_rtc.o --- ctfconvert -L VERSION -g subr_rtc.o --- subr_taskqueue.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/subr_taskqueue.c --- subr_rman.o --- ctfconvert -L VERSION -g subr_rman.o --- subr_trap.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/subr_trap.c --- subr_smp.o --- ctfconvert -L VERSION -g subr_smp.o --- subr_witness.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/kern/subr_witness.c --- subr_taskqueue.o --- ctfconvert -L VERSION -g subr_taskqueue.o --- if.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/net/if.c --- subr_trap.o --- ctfconvert -L VERSION -g subr_trap.o --- netisr.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/net/netisr.c --- subr_bus.o --- ctfconvert -L VERSION -g subr_bus.o --- OsdEnvironment.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/arm64/acpica/OsdEnvironment.c ctfconvert -L VERSION -g OsdEnvironment.o --- autoconf.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/arm64/arm64/autoconf.c --- netisr.o --- ctfconvert -L VERSION -g netisr.o --- busdma_bounce.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/arm64/arm64/busdma_bounce.c --- autoconf.o --- ctfconvert -L VERSION -g autoconf.o --- busdma_machdep.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/arm64/arm64/busdma_machdep.c ctfconvert -L VERSION -g busdma_machdep.o --- mp_machdep.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/arm64/arm64/mp_machdep.c --- subr_witness.o --- ctfconvert -L VERSION -g subr_witness.o --- ofw_machdep.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/arm64/arm64/ofw_machdep.c --- busdma_bounce.o --- ctfconvert -L VERSION -g busdma_bounce.o --- pmap.o --- --- ofw_machdep.o --- /usr/src/sys/arm64/arm64/ofw_machdep.c:52:7: error: assigning to 'bus_space_tag_t' (aka 'struct bus_space *') from incompatible type 'struct bus_space'; take the address with & *tag = memmap_bus; ^ ~~~~~~~~~~ & 1 error generated. --- pmap.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/arm64/arm64/pmap.c --- ofw_machdep.o --- *** [ofw_machdep.o] Error code 1 make[2]: stopped in /usr/obj/arm64.aarch64/usr/src/sys/GENERIC --- mp_machdep.o --- ctfconvert -L VERSION -g mp_machdep.o --- if.o --- ctfconvert -L VERSION -g if.o --- pmap.o --- ctfconvert -L VERSION -g pmap.o 1 error make[2]: stopped in /usr/obj/arm64.aarch64/usr/src/sys/GENERIC *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson452740299164461723.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::104:1 -alias + sudo umount FreeBSD_HEAD_arm64/usr/src + sudo umount FreeBSD_HEAD_arm64/dev + sudo rm -fr FreeBSD_HEAD_arm64 + true + sudo chflags -R noschg FreeBSD_HEAD_arm64 + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Sat Jan 2 23:00:26 2016 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 24E04A5F2AB for ; Sat, 2 Jan 2016 23:00:26 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 1229A1740; Sat, 2 Jan 2016 23:00:26 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id B76AC194E; Sat, 2 Jan 2016 23:00:25 +0000 (UTC) Date: Sat, 2 Jan 2016 23:00:22 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: kib@FreeBSD.org, ian@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <695391794.95.1451775624889.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1014471237.93.1451768402177.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1014471237.93.1451768402177.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #2036 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jan 2016 23:00:26 -0000 FreeBSD_HEAD_arm64 - Build #2036 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2036/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2036/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2036/console Change summaries: 293060 by ian: Fix the arm64 build by adding an all-important '&' to get a pointer. I'm not sure how I missed the error when I test-built here, I guess the pointy hat must have slipped down over my eyes. 293059 by kib: Hide transient EBADF errors caused by the parallel revoke(2) or forced unmount of devfs mounts, by restarting the failed syscall. When restarted, failing syscalls eventually either stop finding the node and returning ENOENT, or the vnode op vectors finally transition to the deadfs vop. The later return EIO or other error, more appropriate for the operation. Submitted by: bde Tested by: pho MFC after: 3 weeks