From owner-freebsd-arm@freebsd.org Sun Dec 20 17:18:14 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F9C1A4D6B4 for ; Sun, 20 Dec 2015 17:18:14 +0000 (UTC) (envelope-from misc.lists@fsck.ch) Received: from secure.socket.ch (secure.socket.ch [91.199.228.84]) (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 C81E917F0 for ; Sun, 20 Dec 2015 17:18:13 +0000 (UTC) (envelope-from misc.lists@fsck.ch) Received: from 46-253-187-21.dynamic.monzoon.net ([46.253.187.21] helo=fluff-wlan.fsck.ch) by secure.socket.ch with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1aAhN2-0004AW-2I for freebsd-arm@freebsd.org; Sun, 20 Dec 2015 18:02:09 +0100 Message-ID: <5676DF0F.1060602@fsck.ch> Date: Sun, 20 Dec 2015 18:02:07 +0100 From: Toby User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Set GPIO at boot on Raspberry Pi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Spam-Report: Spam detection software, running on the system "secure.socket.ch", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hi all Is there a way to set GPIOs at boot? I'd like to set GPIO 28 to out and high before usb devices are probed, in order to be able to use my usb disk. If I have it plugged in during boot, I can't get it to work. It works though if I boot the pi, then plug in the disk and then set the pin to high. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 TVD_RCVD_IP Message was received from an IP address -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-SA-Exim-Connect-IP: 46.253.187.21 X-SA-Exim-Mail-From: misc.lists@fsck.ch X-SA-Exim-Scanned: No (on secure.socket.ch); SAEximRunCond expanded to false X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2015 17:18:14 -0000 Hi all Is there a way to set GPIOs at boot? I'd like to set GPIO 28 to out and high before usb devices are probed, in order to be able to use my usb disk. If I have it plugged in during boot, I can't get it to work. It works though if I boot the pi, then plug in the disk and then set the pin to high. Thanks, Toby From owner-freebsd-arm@freebsd.org Sun Dec 20 17:20:56 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 45492A4D82B for ; Sun, 20 Dec 2015 17:20:56 +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 0B42819DA for ; Sun, 20 Dec 2015 17:20:54 +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 747D02285DE for ; Sun, 20 Dec 2015 11:20:46 -0600 (CST) Subject: Re: Set GPIO at boot on Raspberry Pi To: freebsd-arm@freebsd.org References: <5676DF0F.1060602@fsck.ch> From: Karl Denninger Message-ID: <5676E368.7080800@denninger.net> Date: Sun, 20 Dec 2015 11:20:40 -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: <5676DF0F.1060602@fsck.ch> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090105090903000300080206" 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, 20 Dec 2015 17:20:56 -0000 This is a cryptographically signed message in MIME format. --------------ms090105090903000300080206 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/20/2015 11:02, Toby wrote: > Hi all > > Is there a way to set GPIOs at boot? I'd like to set GPIO 28 to out and= > high before usb devices are probed, in order to be able to use my usb > disk. If I have it plugged in during boot, I can't get it to work. It > works though if I boot the pi, then plug in the disk and then set the > pin to high. > > Thanks, > Toby I've had good luck setting the state FIRST, then the pin config to desired (in this case, OUT.) I have this general problem with driving a relay board, in that the jackwads that designed the board set it up to be active LOW, so if you set the config first you chatter the outputs, and FreeBSD's GPIO config rejects "active low" config as a setting. The pins should come up configured as inputs so the peripheral shouldn't be upset about that. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms090105090903000300080206 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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMjAxNzIwNDBaME8GCSqGSIb3DQEJBDFCBECy W4icXUMswFg8y4Zkgr3Nr0/RdsvZssb+w9Tz+rFSKNc4kZiZe+GFcvKjoLzOeaAwde/iqLON gOcOyVJgmHI7MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAKVhMFa8Q EwmtdBPqAeHZ9uFrTJAC3dD1hzrokJDunEx2Y4dmoOwc5gCXosmyiOh0rAHqkVvR5MaftDBF Og3sN2QLvvvv1UN3TxaKsndrIsWRa82RlH4R3m7fV7V6wmJ/mfuPqrEE4IA1QnIfS5MIjw5u lALOcGIfFvzp2W7p1LWwaaINB9dG7g2rnnKi0QQkIwm5hKiXygd9Ayp0FSLsMxH7F6BHcOMz ww7xRjaTfb5Nz1Bc7WGCtngBwUw1HGNyq5y4FDHwBpTqROrVQIy0n5IdgpTVGVvfFuVfcMAv yTeQ5VhUFvFTLQMeKFIfCYmdrz1KmpECZWPiuVMEEB+sftk02oVjq2APa55IRyA5KWUIpqXB cNXMxq5MEaZAv/lom3/GdJ1BusSuE+g3rkcwtxD2QNoo7sAWZsiIj0G4vlwHfmtmBfoQjE0M 849iBAWVAvRIhK961eWEK/inu4WRrABTmHQ5F0tQKbbhPVH+8D/wQT7L0c/Mo9zUp9TzWP2O 7oHuWi8f65/HE+6XF582/7LVdYy3xpTArAjcrd2JJV8llWQkuKaMqN3dL0s1H7DnkrJp59dt SjIsDqEE139v+ceBdEtBOFYKUU8iUB02nfOgA47Uo3O3DeTn9Y42Q9dGM06dsOTClmP6mbpe eqjRtZMtiLMLeCtRCLnuvLTGO64AAAAAAAA= --------------ms090105090903000300080206-- From owner-freebsd-arm@freebsd.org Sun Dec 20 17:42: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 9A5B5A4DA40 for ; Sun, 20 Dec 2015 17:42:54 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F4F81AA1 for ; Sun, 20 Dec 2015 17:42:54 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sun, 20 Dec 2015 17:43:00 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBKHglkf032264; Sun, 20 Dec 2015 10:42:47 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1450633367.25138.145.camel@freebsd.org> Subject: Re: Set GPIO at boot on Raspberry Pi From: Ian Lepore To: Karl Denninger , freebsd-arm@freebsd.org Date: Sun, 20 Dec 2015 10:42:47 -0700 In-Reply-To: <5676E368.7080800@denninger.net> References: <5676DF0F.1060602@fsck.ch> <5676E368.7080800@denninger.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: Sun, 20 Dec 2015 17:42:54 -0000 On Sun, 2015-12-20 at 11:20 -0600, Karl Denninger wrote: > On 12/20/2015 11:02, Toby wrote: > > Hi all > > > > Is there a way to set GPIOs at boot? I'd like to set GPIO 28 to out > > and > > high before usb devices are probed, in order to be able to use my > > usb > > disk. If I have it plugged in during boot, I can't get it to work. > > It > > works though if I boot the pi, then plug in the disk and then set > > the > > pin to high. > > > > Thanks, > > Toby > I've had good luck setting the state FIRST, then the pin config to > desired (in this case, OUT.) > > I have this general problem with driving a relay board, in that the > jackwads that designed the board set it up to be active LOW, so if > you > set the config first you chatter the outputs, and FreeBSD's GPIO > config > rejects "active low" config as a setting. > > The pins should come up configured as inputs so the peripheral > shouldn't > be upset about that. > I'm not sure what you mean by "FreeBSD's GPIO config rejects active low" -- what config are you refering to? But I don't think pin state when changing config is quite what Toby was asking; he needs a way to configure driven pins very early in boot. Right now we have no way of preconfiguring gpio pins to be driven a certain way early in boot. By manipulating the device-tree data you can configure a pin as input or output, and usually you can configure pull up/down values for inputs, but there's no standard device-tree syntax to configure the drive value when configuring a pin to be driven. Maybe we could add some dev.gpioc tunables so that pins could be configured via loader.conf. -- Ian From owner-freebsd-arm@freebsd.org Sun Dec 20 18:56: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 42B73A4E390 for ; Sun, 20 Dec 2015 18:56:16 +0000 (UTC) (envelope-from misc.lists@fsck.ch) Received: from secure.socket.ch (secure.socket.ch [91.199.228.84]) (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 069FC19D1 for ; Sun, 20 Dec 2015 18:56:15 +0000 (UTC) (envelope-from misc.lists@fsck.ch) Received: from 46-253-187-21.dynamic.monzoon.net ([46.253.187.21] helo=fluff-wlan.fsck.ch) by secure.socket.ch with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1aAj9K-0004jp-VR for freebsd-arm@freebsd.org; Sun, 20 Dec 2015 19:56:12 +0100 Message-ID: <5676F9C6.9050904@fsck.ch> Date: Sun, 20 Dec 2015 19:56:06 +0100 From: Toby User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Set GPIO at boot on Raspberry Pi References: <5676DF0F.1060602@fsck.ch> <5676E368.7080800@denninger.net> <1450633367.25138.145.camel@freebsd.org> In-Reply-To: <1450633367.25138.145.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Spam-Report: Spam detection software, running on the system "secure.socket.ch", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 20/12/15 18:42, Ian Lepore wrote: > But I don't think pin state when changing config is quite what Toby was > asking; he needs a way to configure driven pins very early in boot. Yes, that was my question. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 TVD_RCVD_IP Message was received from an IP address -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-SA-Exim-Connect-IP: 46.253.187.21 X-SA-Exim-Mail-From: misc.lists@fsck.ch X-SA-Exim-Scanned: No (on secure.socket.ch); SAEximRunCond expanded to false X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2015 18:56:16 -0000 On 20/12/15 18:42, Ian Lepore wrote: > But I don't think pin state when changing config is quite what Toby was > asking; he needs a way to configure driven pins very early in boot. Yes, that was my question. > Right now we have no way of preconfiguring gpio pins to be driven a > certain way early in boot. By manipulating the device-tree data you > can configure a pin as input or output, and usually you can configure > pull up/down values for inputs, but there's no standard device-tree > syntax to configure the drive value when configuring a pin to be > driven. Can you be a bit more specific on how I would do that? > Maybe we could add some dev.gpioc tunables so that pins could be > configured via loader.conf. That's what linux has, setting max_usb_current=1 in their /boot/config.txt sets GPIO38 to high. I don't know if they have a generic way of configuring pins though. Thanks, Toby From owner-freebsd-arm@freebsd.org Sun Dec 20 19:27:41 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 F3E5CA4D61A for ; Sun, 20 Dec 2015 19:27:40 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps.rulingia.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F2D519D3 for ; Sun, 20 Dec 2015 19:27:39 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (c122-106-195-17.belrs5.nsw.optusnet.com.au [122.106.195.17]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id tBKJ2wv3044754 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 21 Dec 2015 06:03:04 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id tBKJ2rev058479 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 21 Dec 2015 06:02:53 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id tBKJ2rqZ058478 for freebsd-arm@freebsd.org; Mon, 21 Dec 2015 06:02:53 +1100 (AEDT) (envelope-from peter) Date: Mon, 21 Dec 2015 06:02:53 +1100 From: Peter Jeremy To: freebsd-arm@freebsd.org Subject: BCM2835 (Raspberry Pi) peripherals Message-ID: <20151220190253.GB67307@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.4.3 (vps.rulingia.com [103.243.244.15]); Mon, 21 Dec 2015 06:03:04 +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: Sun, 20 Dec 2015 19:27:41 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD doesn't currently include kernel support for a number of BCM2835 peripherals - the random number generator and being able to do DMA into the PWM (driving it as a serialiser) are of current interest to me. Is anyone working on either of these? --=20 Peter Jeremy --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJWdvtdXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs078YP/38BvtyYDFFdvkZl5F86qDwp dI7703etX3CNyeOlopea1YqSZjzoJIPuhRxyHb6MwRqiG5UNiwi9DKcpmsh4F2P9 ZvMmNhGBsp4wXJHQLSn3m6eKUlqespn32uZbqXlWlHNooNigCspRJYhF0fm7AiKU oznD83Ar1PthzYWk0Ap6cjGQOvAIBFY3rQm1KHM1MO0XLbxQWgZQ3MUNxYRDZoVe t1EwjZAnSTz5GMx0bdQo1RWYjHmzWuc6WTxYxwjVVsb5iI9RTwhhtCQgyDy1mc66 lkv5PFbL/djG5kxTrTbFHMTSvNrio63aVIrRhUko1igEVqO90fZVcOUyxZLCPppP clKrJ6avEJsdjsvxH+VHLpFsg5d7e6KvyE3tN8bk1B5zsww4m5qbWB85GCRi8+wv ernMTKqNkKO49EzzHcSIt7HBGPLzeB/WHzK4AhOzZWulvK2PRhkL0OwW11evJF3r YM0N1KfkB+PR5SR/PAuEZLfjb6hNo7fBqg8hN8x6j554D7oTWJ+MYum24ga0lnhA i897UF40ca18eBs1VBikjivWqriO2Fv7Nem9eduglLfW0YchFL2ZRBzo5tDxwkrm 97mdJqYewCh4bt5BCjuRhdVr5em3ICI5+npULt+Z7+H7WUlu1/2YQxV8AwpVsRpY kFqG9A8m2TgLM6p+Lco+ =basM -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- From owner-freebsd-arm@freebsd.org Sun Dec 20 20:17: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 B0C30A4D72F for ; Sun, 20 Dec 2015 20:17:28 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm34-vm3.bullet.mail.bf1.yahoo.com (nm34-vm3.bullet.mail.bf1.yahoo.com [72.30.239.75]) (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 4ADC71FE5 for ; Sun, 20 Dec 2015 20:17:28 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1450642454; bh=XpxMvottz8X7mfVjra6qRYjKs1dv/kAyMcnypxOcCtM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=Tc2kTr6v3PQ5PcPS1AuQSzPluSKy2WdTLm5SVNojAbOdZAGRgtNaYzGoxccHBdzWiol3TBxOOteJcxf0PMG3zIeLoXJcamkW4HXJypxWqIy7Aa7YlHt9riZ7V+6jAu0MtNO93OV6gxQ+pSV1EHTUeY1i55Z/ucCygRYyQzebC/gUMHU2w48+DC+pLbyy3FP7ADoFH6v1ObX+PIS03Z3LpRw5UGaFEbuEvyYG4DqAy2jD5uUNjVvHcK4NohT4IDZmB+824fFgvViykJKY4QNMFIGk6VxKhNwJT3RoqASvdcJI3QUmSKpW4lk4MfKMIp23wZNd2LqqLPAQqTS5kG+CrA== Received: from [98.139.215.140] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 20 Dec 2015 20:14:14 -0000 Received: from [98.139.211.161] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 20 Dec 2015 20:14:14 -0000 Received: from [127.0.0.1] by smtp218.mail.bf1.yahoo.com with NNFMP; 20 Dec 2015 20:14:14 -0000 X-Yahoo-Newman-Id: 644266.36858.bm@smtp218.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Kz8vUqoVM1kfWkpEJc1DPZPjyyoKaaHshBUYNUeJdYAZEz1 dEiuDhkIffCCy_IuH7fkHw3d9qYVrn..REHaWLoKZmJhgB_MBHvmsdekWip6 YOm_fFRmpRos7Ir2phdO_P_f2aYN7nLyTeW3HkzKMP3VpofY4iF6TpRZpTJQ Qa0HAx0y.02YlOj2nuYr2efSW3BE1nb_puE9ZQnWNA6sYNxSK.aHm2_zkNJs FP_bao4NUm6c0uxQsxC32IwLxj8Xg_6Gwj0RnqbQFkeH9qJ76XEMPd5JsUwL SkPmLFoBpYbveK9P30K.CHm6tSn4ou2VTZmGVC07LbRU8ZGkXi23W6X2B9rj Kprl2eyjKLCyjmccc5ZaWUJYOIugrRV91kHD2hzXROFmhxWJjqeUqMCX64vL Ed5OokF2BlkxbtYrGmMpM2DA3joXP2FsTJ5rUpl2aRqBCXrcQihVP9Akvw5K vsQAzTFyZeZOMihiCvKKYUutLtxv1lMJNoZkaDdy9int2bLSwEVONlRSH8bC Qe4R_RpDsdOZx0H8w1P9xtVkWgFvHyf_yXWWEZy5LlNe6PSvC X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV Content-Type: multipart/mixed; boundary="Apple-Mail=_2EBD3790-110C-4818-8F3E-DA21896228AC" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: u-boot and ubldr on arm64 From: Thomas Skibo In-Reply-To: Date: Sun, 20 Dec 2015 12:14:12 -0800 Cc: "freebsd-arm@freebsd.org" Message-Id: <195ED9AE-7759-4833-846D-949BD6F85735@yahoo.com> References: <5695944F-A052-4959-8F9A-ACD4CD3413D6@yahoo.com> To: Adrian Chadd 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: Sun, 20 Dec 2015 20:17:28 -0000 --Apple-Mail=_2EBD3790-110C-4818-8F3E-DA21896228AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 18, 2015, at 3:24 PM, Adrian Chadd = wrote: >=20 > hey cool! >=20 > Can you post your patches to freebsd and uboot? Let's get them > somewhere reviewed! >=20 >=20 > -a >=20 >=20 Ok. I=E2=80=99m attaching my changes so far. I=E2=80=99ve run out of time = to play with this until after the holidays. I=E2=80=99ve attached an unrelated patch to sys/arm64/arm64/machdep.c = that gets me up and running with an FDT kernel. Opinions welcome from = the arm64 guys. Cheers, =E2=80=94Thomas =E2=80=94 Thomas Skibo thomasskibo@yahoo.com --Apple-Mail=_2EBD3790-110C-4818-8F3E-DA21896228AC 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 292455) +++ 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 292455) +++ 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 --- /dev/null 2015-12-19 17:44:00.000000000 -0800 +++ sys/boot/arm64/Makefile.inc 2015-12-19 17:47:30.916631000 -0800 @@ -0,0 +1,3 @@ +# $FreeBSD$ + +.include "../Makefile.inc" 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 --- /dev/null 2015-12-19 17:44:00.000000000 -0800 +++ sys/boot/arm64/uboot/version 2015-12-12 07:04:07.979566000 = -0800 @@ -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/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 --- /dev/null 2015-12-19 17:44:00.000000000 -0800 +++ sys/boot/arm64/uboot/conf.c 2015-12-12 07:02:16.820511000 -0800 @@ -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 +}; 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 --- /dev/null 2015-12-19 17:44:00.000000000 -0800 +++ sys/boot/arm64/uboot/Makefile 2015-12-17 09:03:26.981847000 = -0800 @@ -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 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 --- /dev/null 2015-12-19 17:44:00.000000000 -0800 +++ sys/boot/arm64/uboot/start.S 2015-12-16 13:38:31.463576000 = -0800 @@ -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 */ 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 --- /dev/null 2015-12-19 17:44:00.000000000 -0800 +++ sys/boot/arm64/uboot/help.uboot 2015-12-12 07:02:24.667806000 = -0800 @@ -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/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 --- /dev/null 2015-12-19 17:44:00.000000000 -0800 +++ sys/boot/arm64/uboot/loader.conf 2015-12-14 12:03:37.518477000 = -0800 @@ -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" 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 --- /dev/null 2015-12-19 17:44:00.000000000 -0800 +++ sys/boot/arm64/uboot/ldscript.aarch64 2015-12-12 = 07:03:01.792999000 -0800 @@ -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/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 292455) +++ 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 292455) +++ sys/boot/efi/loader/bootinfo.c (working copy) @@ -217,7 +217,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); @@ -360,7 +360,7 @@ vm_offset_t dtbp; int dtb_size; #endif -#if defined(__arm__) +#if defined(__arm__) || defined(__aarch64__) vm_offset_t vaddr; int i; /* @@ -448,7 +448,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 292455) +++ 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); } @@ -605,7 +605,7 @@ } =20 /* If ldvar is malformed or there's no variable name left, punt. = */ - if (ldvar[0] =3D=3D 0 || var[0] =3D=3D 0) + if ((action =3D=3D UBENV_IMPORT && ldvar[0] =3D=3D 0) || var[0] = =3D=3D 0) return; =20 val =3D ub_env_get(var); 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 292455) +++ 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 292455) +++ 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 292455) +++ 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 292455) +++ 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 292455) +++ 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 292455) +++ 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,14 +130,14 @@ ub_putc(char c) { =20 - syscall(API_PUTC, NULL, (uint32_t)&c); + syscall(API_PUTC, NULL, (uintptr_t)&c); } =20 void 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=_2EBD3790-110C-4818-8F3E-DA21896228AC Content-Disposition: attachment; filename=u-boot-patches.txt Content-Type: text/plain; name="u-boot-patches.txt" Content-Transfer-Encoding: quoted-printable diff --git a/api/api.c b/api/api.c index c5f6edb..2639ee5 100644 --- a/api/api.c +++ b/api/api.c @@ -52,7 +52,7 @@ static int API_getc(va_list ap) { int *c; =20 - if ((c =3D (int *)va_arg(ap, u_int32_t)) =3D=3D NULL) + if ((c =3D (int *)va_arg(ap, uintptr_t)) =3D=3D NULL) return API_EINVAL; =20 *c =3D getc(); @@ -68,7 +68,7 @@ static int API_tstc(va_list ap) { int *t; =20 - if ((t =3D (int *)va_arg(ap, u_int32_t)) =3D=3D NULL) + if ((t =3D (int *)va_arg(ap, uintptr_t)) =3D=3D NULL) return API_EINVAL; =20 *t =3D tstc(); @@ -84,7 +84,7 @@ static int API_putc(va_list ap) { char *c; =20 - if ((c =3D (char *)va_arg(ap, u_int32_t)) =3D=3D NULL) + if ((c =3D (char *)va_arg(ap, uintptr_t)) =3D=3D NULL) return API_EINVAL; =20 putc(*c); @@ -100,7 +100,7 @@ static int API_puts(va_list ap) { char *s; =20 - if ((s =3D (char *)va_arg(ap, u_int32_t)) =3D=3D NULL) + if ((s =3D (char *)va_arg(ap, uintptr_t)) =3D=3D NULL) return API_EINVAL; =20 puts(s); @@ -132,7 +132,7 @@ static int API_get_sys_info(va_list ap) { struct sys_info *si; =20 - si =3D (struct sys_info *)va_arg(ap, u_int32_t); + si =3D (struct sys_info *)va_arg(ap, uintptr_t); if (si =3D=3D NULL) return API_ENOMEM; =20 @@ -148,7 +148,7 @@ static int API_udelay(va_list ap) { unsigned long *d; =20 - if ((d =3D (unsigned long *)va_arg(ap, u_int32_t)) =3D=3D NULL) + if ((d =3D (unsigned long *)va_arg(ap, uintptr_t)) =3D=3D NULL) return API_EINVAL; =20 udelay(*d); @@ -164,11 +164,11 @@ static int API_get_timer(va_list ap) { unsigned long *base, *cur; =20 - cur =3D (unsigned long *)va_arg(ap, u_int32_t); + cur =3D (unsigned long *)va_arg(ap, uintptr_t); if (cur =3D=3D NULL) return API_EINVAL; =20 - base =3D (unsigned long *)va_arg(ap, u_int32_t); + base =3D (unsigned long *)va_arg(ap, uintptr_t); if (base =3D=3D NULL) return API_EINVAL; =20 @@ -199,7 +199,7 @@ static int API_dev_enum(va_list ap) struct device_info *di; =20 /* arg is ptr to the device_info struct we are going to fill out = */ - di =3D (struct device_info *)va_arg(ap, u_int32_t); + di =3D (struct device_info *)va_arg(ap, uintptr_t); if (di =3D=3D NULL) return API_EINVAL; =20 @@ -233,7 +233,7 @@ static int API_dev_open(va_list ap) int err =3D 0; =20 /* arg is ptr to the device_info struct */ - di =3D (struct device_info *)va_arg(ap, u_int32_t); + di =3D (struct device_info *)va_arg(ap, uintptr_t); if (di =3D=3D NULL) return API_EINVAL; =20 @@ -265,7 +265,7 @@ static int API_dev_close(va_list ap) int err =3D 0; =20 /* arg is ptr to the device_info struct */ - di =3D (struct device_info *)va_arg(ap, u_int32_t); + di =3D (struct device_info *)va_arg(ap, uintptr_t); if (di =3D=3D NULL) return API_EINVAL; =20 @@ -319,7 +319,7 @@ static int API_dev_write(va_list ap) int err =3D 0; =20 /* 1. arg is ptr to the device_info struct */ - di =3D (struct device_info *)va_arg(ap, u_int32_t); + di =3D (struct device_info *)va_arg(ap, uintptr_t); if (di =3D=3D NULL) return API_EINVAL; =20 @@ -329,12 +329,12 @@ static int API_dev_write(va_list ap) return API_ENODEV; =20 /* 2. arg is ptr to buffer from where to get data to write */ - buf =3D (void *)va_arg(ap, u_int32_t); + buf =3D (void *)va_arg(ap, uintptr_t); if (buf =3D=3D NULL) return API_EINVAL; =20 /* 3. arg is length of buffer */ - len =3D (int *)va_arg(ap, u_int32_t); + len =3D (int *)va_arg(ap, uintptr_t); if (len =3D=3D NULL) return API_EINVAL; if (*len <=3D 0) @@ -387,7 +387,7 @@ static int API_dev_read(va_list ap) int *len_net, *act_len_net; =20 /* 1. arg is ptr to the device_info struct */ - di =3D (struct device_info *)va_arg(ap, u_int32_t); + di =3D (struct device_info *)va_arg(ap, uintptr_t); if (di =3D=3D NULL) return API_EINVAL; =20 @@ -397,23 +397,23 @@ static int API_dev_read(va_list ap) return API_ENODEV; =20 /* 2. arg is ptr to buffer from where to put the read data */ - buf =3D (void *)va_arg(ap, u_int32_t); + buf =3D (void *)va_arg(ap, uintptr_t); if (buf =3D=3D NULL) return API_EINVAL; =20 if (di->type & DEV_TYP_STOR) { /* 3. arg - ptr to var with # of blocks to read */ - len_stor =3D (lbasize_t *)va_arg(ap, u_int32_t); + len_stor =3D (lbasize_t *)va_arg(ap, uintptr_t); if (!len_stor) return API_EINVAL; if (*len_stor <=3D 0) return API_EINVAL; =20 /* 4. arg - ptr to var with start block */ - start =3D (lbastart_t *)va_arg(ap, u_int32_t); + start =3D (lbastart_t *)va_arg(ap, uintptr_t); =20 /* 5. arg - ptr to var where to put the len actually = read */ - act_len_stor =3D (lbasize_t *)va_arg(ap, u_int32_t); + act_len_stor =3D (lbasize_t *)va_arg(ap, uintptr_t); if (!act_len_stor) return API_EINVAL; =20 @@ -422,14 +422,14 @@ static int API_dev_read(va_list ap) } else if (di->type & DEV_TYP_NET) { =20 /* 3. arg points to the var with length of packet to = read */ - len_net =3D (int *)va_arg(ap, u_int32_t); + len_net =3D (int *)va_arg(ap, uintptr_t); if (!len_net) return API_EINVAL; if (*len_net <=3D 0) return API_EINVAL; =20 /* 4. - ptr to var where to put the len actually read */ - act_len_net =3D (int *)va_arg(ap, u_int32_t); + act_len_net =3D (int *)va_arg(ap, uintptr_t); if (!act_len_net) return API_EINVAL; =20 @@ -453,9 +453,9 @@ static int API_env_get(va_list ap) { char *name, **value; =20 - if ((name =3D (char *)va_arg(ap, u_int32_t)) =3D=3D NULL) + if ((name =3D (char *)va_arg(ap, uintptr_t)) =3D=3D NULL) return API_EINVAL; - if ((value =3D (char **)va_arg(ap, u_int32_t)) =3D=3D NULL) + if ((value =3D (char **)va_arg(ap, uintptr_t)) =3D=3D NULL) return API_EINVAL; =20 *value =3D getenv(name); @@ -476,9 +476,9 @@ static int API_env_set(va_list ap) { char *name, *value; =20 - if ((name =3D (char *)va_arg(ap, u_int32_t)) =3D=3D NULL) + if ((name =3D (char *)va_arg(ap, uintptr_t)) =3D=3D NULL) return API_EINVAL; - if ((value =3D (char *)va_arg(ap, u_int32_t)) =3D=3D NULL) + if ((value =3D (char *)va_arg(ap, uintptr_t)) =3D=3D NULL) return API_EINVAL; =20 setenv(name, value); @@ -498,9 +498,9 @@ static int API_env_enum(va_list ap) int i, n; char *last, **next; =20 - last =3D (char *)va_arg(ap, u_int32_t); + last =3D (char *)va_arg(ap, uintptr_t); =20 - if ((next =3D (char **)va_arg(ap, u_int32_t)) =3D=3D NULL) + if ((next =3D (char **)va_arg(ap, uintptr_t)) =3D=3D NULL) return API_EINVAL; =20 if (last =3D=3D NULL) @@ -586,7 +586,7 @@ static cfp_t calls_table[API_MAXCALL] =3D { NULL, }; * The main syscall entry point - this is not reentrant, only one call = is * serviced until finished. * - * e.g. syscall(1, int *, u_int32_t, u_int32_t, u_int32_t, u_int32_t); + * e.g. syscall(1, int *, uintptr_t, uintptr_t, uintptr_t, uintptr_t); * * call: syscall number * diff --git a/examples/api/crt0.S b/examples/api/crt0.S index 78d35a2..eb6312e 100644 --- a/examples/api/crt0.S +++ b/examples/api/crt0.S @@ -25,6 +25,22 @@ syscall: mtctr %r11 bctr =20 +#elif defined(CONFIG_ARM64) + + .text + .globl _start +_start: + ldr x14, =3Dsearch_hint + mov x15, sp + str x15, [x14] + b main + + + .globl syscall +syscall: + ldr x15, syscall_ptr + br x15 + #elif defined(CONFIG_ARM) =20 .text @@ -45,10 +61,10 @@ syscall: #endif =20 .globl syscall_ptr + .align 3 syscall_ptr: - .align 4 - .long 0 + .quad 0 =20 .globl search_hint search_hint: - .long 0 + .quad 0 diff --git a/examples/api/demo.c b/examples/api/demo.c index 8c30457..e1693ef 100644 --- a/examples/api/demo.c +++ b/examples/api/demo.c @@ -43,12 +43,11 @@ int main(int argc, char * const argv[]) if (sig->version > API_SIG_VERSION) return -3; =20 - printf("API signature found @%x\n", (unsigned int)sig); + printf("API signature found @0x%p\n", sig); test_dump_sig(sig); =20 printf("\n*** Consumer API test ***\n"); - printf("syscall ptr 0x%08x@%08x\n", (unsigned int)syscall_ptr, - (unsigned int)&syscall_ptr); + printf("syscall ptr 0x%p @0x%p\n", syscall_ptr, &syscall_ptr); =20 /* console activities */ ub_putc('B'); @@ -203,7 +202,7 @@ void test_dump_sig(struct api_signature *sig) printf("signature:\n"); printf(" version\t=3D %d\n", sig->version); printf(" checksum\t=3D 0x%08x\n", sig->checksum); - printf(" sc entry\t=3D 0x%08x\n", (unsigned int)sig->syscall); + printf(" sc entry\t=3D 0x%p\n", (void *)sig->syscall); } =20 void test_dump_si(struct sys_info *si) @@ -296,7 +295,7 @@ void test_dump_di(int handle) struct device_info *di =3D ub_dev_get(handle); =20 printf("device info (%d):\n", handle); - printf(" cookie\t=3D 0x%08x\n", (uint32_t)di->cookie); + printf(" cookie\t=3D 0x%p\n", di->cookie); printf(" type\t\t=3D 0x%08x\n", di->type); =20 if (di->type =3D=3D DEV_TYP_NET) { diff --git a/examples/api/glue.c b/examples/api/glue.c index d619518..d5c1809 100644 --- a/examples/api/glue.c +++ b/examples/api/glue.c @@ -41,8 +41,8 @@ static int valid_sig(struct api_signature *sig) int api_search_sig(struct api_signature **sig) { unsigned char *sp; - uint32_t search_start =3D 0; - uint32_t search_end =3D 0; + uintptr_t search_start =3D 0; + uintptr_t search_end =3D 0; =20 if (sig =3D=3D NULL) return 0; @@ -77,7 +77,7 @@ int ub_getc(void) { int c; =20 - if (!syscall(API_GETC, NULL, (uint32_t)&c)) + if (!syscall(API_GETC, NULL, (uintptr_t)&c)) return -1; =20 return c; @@ -87,7 +87,7 @@ int ub_tstc(void) { int t; =20 - if (!syscall(API_TSTC, NULL, (uint32_t)&t)) + if (!syscall(API_TSTC, NULL, (uintptr_t)&t)) return -1; =20 return t; @@ -95,12 +95,12 @@ int ub_tstc(void) =20 void ub_putc(char c) { - syscall(API_PUTC, NULL, (uint32_t)&c); + syscall(API_PUTC, NULL, (uintptr_t)&c); } =20 void ub_puts(const char *s) { - syscall(API_PUTS, NULL, (uint32_t)s); + syscall(API_PUTS, NULL, (uintptr_t)s); } =20 /**************************************** @@ -126,7 +126,7 @@ struct sys_info * ub_get_sys_info(void) 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); @@ -344,7 +344,7 @@ char * ub_env_get(const char *name) { 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; @@ -352,7 +352,7 @@ char * ub_env_get(const char *name) =20 void ub_env_set(const char *name, char *value) { - 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]; @@ -369,7 +369,7 @@ const char * ub_env_enum(const char *last) * 'name=3Dval' string), since the API_ENUM_ENV call uses = envmatch() * internally, which handles such case */ - 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) @@ -396,7 +396,8 @@ int ub_display_get_info(int type, struct = display_info *di) { int err =3D 0; =20 - if (!syscall(API_DISPLAY_GET_INFO, &err, (uint32_t)type, = (uint32_t)di)) + if (!syscall(API_DISPLAY_GET_INFO, &err, (uintptr_t)type, + (uintptr_t)di)) return API_ESYSC; =20 return err; diff --git a/examples/api/glue.h b/examples/api/glue.h index 91c8c1c..3e27a4e 100644 --- a/examples/api/glue.h +++ b/examples/api/glue.h @@ -19,7 +19,7 @@ #define UB_MAX_DEV 6 /* max devices number */ =20 extern void *syscall_ptr; -extern uint32_t search_hint; +extern uintptr_t search_hint; =20 int syscall(int, int *, ...); int api_search_sig(struct api_signature **sig); diff --git a/examples/api/libgenwrap.c b/examples/api/libgenwrap.c index c1afa5b..4f78c15 100644 --- a/examples/api/libgenwrap.c +++ b/examples/api/libgenwrap.c @@ -23,7 +23,7 @@ int printf (const char *fmt, ...) { va_list args; uint i; - char printbuffer[256]; + char printbuffer[512]; =20 va_start (args, fmt); =20 --Apple-Mail=_2EBD3790-110C-4818-8F3E-DA21896228AC Content-Disposition: attachment; filename=machdep-patch.txt Content-Type: text/plain; name="machdep-patch.txt" Content-Transfer-Encoding: 7bit Index: sys/arm64/arm64/machdep.c =================================================================== --- sys/arm64/arm64/machdep.c (revision 292455) +++ sys/arm64/arm64/machdep.c (working copy) @@ -766,8 +766,19 @@ try_load_dtb(caddr_t kmdp) { vm_offset_t dtbp; + struct mem_region mem_regions[FDT_MEM_REGIONS]; + uint32_t memsize; /* XXX: fdt_get_mem_regions() can't handle 64-bit */ + int i, mem_regions_sz; dtbp = MD_FETCH(kmdp, MODINFOMD_DTBP, vm_offset_t); +#ifdef FDT_DTB_STATIC + /* + * If the device tree blob was not retrieved from metadata, + * try to use the statically embedded one. + */ + if (dtbp == (vm_offset_t)NULL) + dtbp = (vm_offset_t)&fdt_static_dtb; +#endif if (dtbp == (vm_offset_t)NULL) { printf("ERROR loading DTB\n"); return; @@ -778,6 +789,19 @@ if (OF_init((void *)dtbp) != 0) panic("OF_init failed with the found device tree"); + + /* Grab physical memory regions information from device tree. */ + if (fdt_get_mem_regions(mem_regions, &mem_regions_sz, &memsize) != 0) { + printf("No physical memory regions in DTB\n"); + return; + } + + for (i = 0; i < mem_regions_sz; i++) { + if (!add_physmap_entry(mem_regions[i].mr_start, + mem_regions[i].mr_size, physmap, + &physmap_idx)) + break; + } } #endif @@ -822,10 +846,6 @@ boothowto = MD_FETCH(kmdp, MODINFOMD_HOWTO, int); kern_envp = MD_FETCH(kmdp, MODINFOMD_ENVP, char *); -#ifdef FDT - try_load_dtb(kmdp); -#endif - /* Find the address to start allocating from */ lastaddr = MD_FETCH(kmdp, MODINFOMD_KERNEND, vm_offset_t); @@ -833,8 +853,13 @@ physmap_idx = 0; efihdr = (struct efi_map_header *)preload_search_info(kmdp, MODINFO_METADATA | MODINFOMD_EFI_MAP); - add_efi_map_entries(efihdr, physmap, &physmap_idx); + if (efihdr != NULL) + add_efi_map_entries(efihdr, physmap, &physmap_idx); +#ifdef FDT + try_load_dtb(kmdp); +#endif + /* Print the memory map */ mem_len = 0; for (i = 0; i < physmap_idx; i += 2) { --Apple-Mail=_2EBD3790-110C-4818-8F3E-DA21896228AC-- From owner-freebsd-arm@freebsd.org Sun Dec 20 21:07:51 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 865C2A4D355 for ; Sun, 20 Dec 2015 21:07:51 +0000 (UTC) (envelope-from misc.lists@fsck.ch) Received: from secure.socket.ch (secure.socket.ch [91.199.228.84]) (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 4B9FB1791 for ; Sun, 20 Dec 2015 21:07:50 +0000 (UTC) (envelope-from misc.lists@fsck.ch) Received: from 46-253-187-21.dynamic.monzoon.net ([46.253.187.21] helo=fluff-wlan.fsck.ch) by secure.socket.ch with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1aAlCk-0005PH-Q3 for freebsd-arm@freebsd.org; Sun, 20 Dec 2015 22:07:48 +0100 Message-ID: <567718A1.7040900@fsck.ch> Date: Sun, 20 Dec 2015 22:07:45 +0100 From: Toby User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Cannot build RBPI2 kernel on pi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Spam-Report: Spam detection software, running on the system "secure.socket.ch", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hi With a fresh checkout of head (I think 292519, but not 100% sure), I cannot build the kernel on my raspberry pi 2. I've started out in multiuser mode, with little else running, 1GB of /tmp and 1GB of /var/tmp and 1.8GB swap (all on an USB stick). [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 TVD_RCVD_IP Message was received from an IP address -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-SA-Exim-Connect-IP: 46.253.187.21 X-SA-Exim-Mail-From: misc.lists@fsck.ch X-SA-Exim-Scanned: No (on secure.socket.ch); SAEximRunCond expanded to false X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2015 21:07:51 -0000 Hi With a fresh checkout of head (I think 292519, but not 100% sure), I cannot build the kernel on my raspberry pi 2. I've started out in multiuser mode, with little else running, 1GB of /tmp and 1GB of /var/tmp and 1.8GB swap (all on an USB stick). make buildkernel KENRCONF=RPI2 fails with the following error: ERROR: ctfmerge: No ctf sections found to merge :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk if_de.kld export_syms | xargs -J% objcopy % if_de.kld ld -Bshareable -d -warn-common -o if_de.ko if_de.kld objcopy --strip-debug if_de.ko ===> dtb/rpi (all) Generating rpi.dtb from rpi.dts converting rpi.dts -> /usr/obj/usr/src/sys/RPI2/modules/usr/src/sys/modules/dtb/rpi/rpi.dtb Unable to open file ./bcm2835.dtsi Segmentation fault (core dumped) *** Error code 139 Stop. make[4]: stopped in /usr/src/sys/modules/dtb/rpi *** Error code 1 Stop. make[3]: stopped in /usr/src/sys/modules *** Error code 1 Thanks for any hints, Toby From owner-freebsd-arm@freebsd.org Mon Dec 21 08:39: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 D620EA4E3E9 for ; Mon, 21 Dec 2015 08:39:25 +0000 (UTC) (envelope-from tom@snnap.net) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B5D71B55 for ; Mon, 21 Dec 2015 08:39:25 +0000 (UTC) (envelope-from tom@snnap.net) Received: by mail-lb0-x233.google.com with SMTP id sv6so4443997lbb.0 for ; Mon, 21 Dec 2015 00:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=snnap-net.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=u8iv9AtydNwSGwtZythrsdaKhhH9AM08nAhqOWorFWQ=; b=hTUGeJwclQO+a0MMbM4NM2xrZkD1nB6SUW7/M/430EjXuyfRwbhno8OPu6vOq6BffT eFzlIL5EF/ixPU7qcGIeGuhubyuWb4zW1aHbzIcJgn37r69EHdjfHuHvjHTscZOM6Bjl C3ow4otbC7yH3B/6l8N2jNS/82P5VS9GfuQOCuz+tRZHooCR+ht8fTa7YCK8yGhOnOF4 JJZ/h/6BS9b3pzJgp8yfuC36+zGNWPrY8YEo2cbEFQlqQth6tKzXaDuUMMT4UVBcyI85 Ic/K+p037Z36GW6nD9OJRfdBc6zVXYVxzaYpsirdd41/TFneO8sryKSLNE3byxlcK9lL ZS4A== 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=u8iv9AtydNwSGwtZythrsdaKhhH9AM08nAhqOWorFWQ=; b=WIUAeluivFWWYKfqxYZsYSvAPJuEzwogP0ETV5pKW8/1RuHkg+Ctg7PWCkcAqHtHdc POSsAwxnj7vh5fby8b8VK+/NQPxuFHOu+l0Jv8TfdU2XK805sZygKUzf0+Dm1/ukiqdS lNvZckxvWThVN5psLZY1Ve/PswK8U8QpA9xFZrvXz62memgZ2Eu1TcXt7W0PI1brT+sX 81le9E1Jv4J9cH5ASgZTHR7Cfo66pcynWHd7XTZptQiNctTAcVIRfVG8npX3RD4gDXnO zxgluTp9O8LPKlqz1jpWop+Ck2FC5pIcF/9uJt+hZzGqMfTZn3iOyteE54X2Nz+jGwpc ovUg== X-Gm-Message-State: ALoCoQm/JMbpYrxv00mVg3FQ4JNWw1REdoK/aJKLQ+Y9KsSXI4M75q5sqGv2+sq5LC/w9rnvwrSPuCRhZelqMNurmOXTCO5ZaA== MIME-Version: 1.0 X-Received: by 10.112.161.228 with SMTP id xv4mr6088763lbb.60.1450687163319; Mon, 21 Dec 2015 00:39:23 -0800 (PST) Received: by 10.112.25.73 with HTTP; Mon, 21 Dec 2015 00:39:23 -0800 (PST) X-Originating-IP: [2001:44b8:3164:6d12:850c:4f50:469:9980] Date: Mon, 21 Dec 2015 19:39:23 +1100 Message-ID: Subject: 10.x stable/release for rpi 2? From: Tom Storey To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 08:39:25 -0000 Sorry, I must be blind or something .. Are there any 10.x stable or release images for the rpi 2? I only see 11 current images for rpi 2, but I see 10.2 (where did 10.1 go?) stable for rpi B. Thanks! From owner-freebsd-arm@freebsd.org Mon Dec 21 13:15:08 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 D89E8A4CA8C for ; Mon, 21 Dec 2015 13:15:08 +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 860E81613 for ; Mon, 21 Dec 2015 13:15:08 +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 A637C228F09 for ; Mon, 21 Dec 2015 07:15:06 -0600 (CST) Subject: Re: 10.x stable/release for rpi 2? To: freebsd-arm@freebsd.org References: From: Karl Denninger Message-ID: <5677FB53.5000106@denninger.net> Date: Mon, 21 Dec 2015 07:14:59 -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: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050508090705040601080905" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 13:15:09 -0000 This is a cryptographically signed message in MIME format. --------------ms050508090705040601080905 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/21/2015 02:39, Tom Storey wrote: > Sorry, I must be blind or something .. > > Are there any 10.x stable or release images for the rpi 2? > > I only see 11 current images for rpi 2, but I see 10.2 (where did 10.1 > go?) stable for rpi B. > > Thanks! > There aren't any for the Rpi 2; at present only 11-Current is available --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050508090705040601080905 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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMjExMzE0NTlaME8GCSqGSIb3DQEJBDFCBEDE yH51o5KIQ7bjwy/HlxC+C9Nu2iUbTXCXKgFA91tAu+AErsX1/aQcCVQqFWAnJR1XyMstMNUm Accxya4HxBzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAimDn+T08 IbI8pHxebs1J/GxQ8lQ+D7uQONK7apX0/WAUv5WWvM9/ARc+iGy2jBT93oUMcuJMWvanAX9g c6bRH543Fjm7K3c/7WxH1+BkbHJGnGzDm1dcZJs+ELI/wNmawkeY3JbI9UcEdGYqU9wwv8GT odUwt5E8hJwroREc3B5TDPVQFUhIpwmWu5MV/ZZAZDHiBW5FOXS3lcjLA+9gPqhOT6wgkCBI RXtvOjR2QDCCWHzie7Ga4ceqBapqfhoXDIbb0GIDNnSqAy/SEKUqa1/y+mz78+jcLwpAZ8Il Ap0puwPQG6OounmP8Z6SBQo6yh5uJkj794ML18WIF8ZzLKWYisLcr+lPKAN3q5uhgYMYC54S 7KaS99Wt3HTmA+Li+LhZ1jhmxgcJ4XUE+yVjlK4Q+I5D7LPB3ZxPXKWWYkgAHEi3/B/NHgDL KtpZUdqMFlY+4oBlyBR48TTi7nx13ib1hYtmBsMMFLjIrHFBQ8urAwXmdBNdy6f6benldkmB UfX8sBW1jSsDmvbhn4XDDYHJHSk4mNPRgGZRP6r9c98JCv4/o5bYvYyfnmmCaTwK+X4u3PK0 adwPnSTcxf91a9yCJRXLxlfdBui62eFY4hHqIQm+zpmNs4/D+Tz2Ag0GFKls+aL910rZfa0A B/k4FD52ttrJ3HJGwgxMYLzxkZwAAAAAAAA= --------------ms050508090705040601080905-- From owner-freebsd-arm@freebsd.org Mon Dec 21 14:04: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 C5333A4E97F for ; Mon, 21 Dec 2015 14:04:12 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D8AD1176 for ; Mon, 21 Dec 2015 14:04:12 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by mail-yk0-x230.google.com with SMTP id x184so132108720yka.3 for ; Mon, 21 Dec 2015 06:04:12 -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=7AWAz99SXuzGt18yVNisG4jt3U/CnTims5Eto4WFxvQ=; b=pJE6TrRK3z3EymoFV3Pg9KIxW98xJhgk9WNB9+sKjRiyr6SEsAk7K501B1VvtbsrOF HewWwCMTjz0VwfmoDxJZUxIBA+Yo1ceNW1/TL866ouUkUWwfOSxc5QzXhTUj9O68q53D /0Vf1GGhDr4hKTvnUms4NTzkk4hNYwUNwDQeFzpr7sbX8FHVkjk8LxhTEN7lLxKmqAi0 ayLlC8C4hHdYkn+iqgZejB8hjqeJyS5pkTCfeZVfXQD7TibkLOQ+pfqVCqvnKtjI2Hu5 LlvjGEZHERaORCM6yGON8il75F63XkIXb2I9VpdUNnfMNij+ltFOv06pq6CVtMss83gw 5Prw== MIME-Version: 1.0 X-Received: by 10.13.249.194 with SMTP id j185mr16327212ywf.66.1450706651586; Mon, 21 Dec 2015 06:04:11 -0800 (PST) Received: by 10.129.97.11 with HTTP; Mon, 21 Dec 2015 06:04:11 -0800 (PST) In-Reply-To: <5676F9C6.9050904@fsck.ch> References: <5676DF0F.1060602@fsck.ch> <5676E368.7080800@denninger.net> <1450633367.25138.145.camel@freebsd.org> <5676F9C6.9050904@fsck.ch> Date: Mon, 21 Dec 2015 12:04:11 -0200 Message-ID: Subject: Re: Set GPIO at boot on Raspberry Pi From: Luiz Otavio O Souza To: Toby 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: Mon, 21 Dec 2015 14:04:12 -0000 On 20 December 2015 at 16:56, Toby wrote: > > That's what linux has, setting max_usb_current=1 in their > /boot/config.txt sets GPIO38 to high. I don't know if they have a > generic way of configuring pins though. > This seems to be a firmware thing, all settings in config.txt are parsed by firmware. After all the high current mode has to be enabled as early as possible to allow the system boot with a high current device plugged in. If the firmware sets this pin high, FreeBSD GPIO driver won't change it. Try to update the firmware and see if that helps. Luiz From owner-freebsd-arm@freebsd.org Mon Dec 21 20:33: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 A50E6A4E0A5 for ; Mon, 21 Dec 2015 20:33:05 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm48-vm4.bullet.mail.bf1.yahoo.com (nm48-vm4.bullet.mail.bf1.yahoo.com [216.109.115.159]) (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 63E1E1D40 for ; Mon, 21 Dec 2015 20:33:05 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1450729815; bh=OuKVloWWxIMlPFMo8etfzalbIxcacSqTI9wziH68+y4=; h=From:Subject:Date:To:From:Subject; b=XvxhJV+TvTzhxrE1NJpA/T9vGBvyM6v4yN7GJMPpkmlqXOH1XwIb9cGxdBmjR87jRG9mJJdv5zMYgdLXeg6rcURFarXumTT1Y7cujYAdUEH/4Rp279deAjX2cnYjOxe78gv9CdmunwJ33xpEdabH7KRTu5aB2Hse0zILE3cxXhE1CP04tzAZoL/f70QeDTiQoPsTtqR5CRfgjczd2OPXB3lThVEnNOs6tItTGNXSZQZqPWi7ASa71+JjlF35KcyOqtiHMJasVxUeBVhVCWI5in2OBN1JEkMgeo2kXDbf1EdugtjZRzT3aBRe2y43iJyFkWy7SzwJnEYGA7rhipYv7g== Received: from [66.196.81.172] by nm48.bullet.mail.bf1.yahoo.com with NNFMP; 21 Dec 2015 20:30:15 -0000 Received: from [98.139.213.14] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 21 Dec 2015 20:30:15 -0000 Received: from [127.0.0.1] by smtp114.mail.bf1.yahoo.com with NNFMP; 21 Dec 2015 20:30:15 -0000 X-Yahoo-Newman-Id: 575597.7474.bm@smtp114.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: JWMdLXUVM1nmDOSIWbQTj_zd8UaVuDkmiZla4cgRjxA88S. AaE9lrxGgW2.7SvV1fLoFuv6ZPaPSp_H.oy9QdIdHIaYI5LancwGh2dt1Mcz .6LKbCj6S3YV94S2ymeXpyykOP_c3R1t8OupldWDCrIIFlvmsuEyBqR56LX2 JMcA4_i63SXSQg2ozWzCzSbhnpsB.trPLkXUEHsWkAdkkWuKz3X0JahOixn. 6aryCVMj7WLMrIY_4tMOCgs0oUrz_PVDS47f4Ml_6ubCRweqOz9dw1TNTQx9 l7n2YbxiwAfYW0LrMbEY3.PRN_uKsKWrH1_PLeCDEL8dpctVbaCKZNJrrnf3 TJ.fU58fjQ5DDrQ.pH.FOiTTZKHU2_jF6nTDwLLUmxngqto4_Ck_F1rVkpH9 QJfs3WykHTYJRtwvSum7FIPiui31zXjr5YOjkxflSiHHmvt.DhkNbPyhR1oM aNAQfp.vwbll8cOg70pHIKAvsNV_XjHg8FJyYY4mu5svIAOvid8hGsIStzL9 eLC9lKd0saYHg4sofL7UK30H2z3Qe3JWRHw4FVfmS4ReHfQZYn6SsQkmN0A- - X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV From: Thomas Skibo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: u-boot and ubldr on arm64 Message-Id: <56FDEDFE-435B-4FA7-85D1-EAD6B5B58AF8@yahoo.com> Date: Mon, 21 Dec 2015 12:30:13 -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: Mon, 21 Dec 2015 20:33:05 -0000 Don=E2=80=99t apply my patches in the previous message, they=E2=80=99re = malformed. Sorry about that. I=E2=80=99ll have to recreate them later. Sorry, =E2=80=94Thomas =E2=80=94=E2=80=94 Thomas Skibo thomasskibo@yahoo.com From owner-freebsd-arm@freebsd.org Mon Dec 21 20:57: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 74B32A4E9DE for ; Mon, 21 Dec 2015 20:57:06 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 599E01D5E; Mon, 21 Dec 2015 20:57:06 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2C167FA3; Mon, 21 Dec 2015 20:57:06 +0000 (UTC) Date: Mon, 21 Dec 2015 20:57:02 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jhb@FreeBSD.org, imp@FreeBSD.org, tuexen@FreeBSD.org, ian@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1722782268.39.1450731425844.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1930 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 20:57:06 -0000 FreeBSD_HEAD_arm64 - Build #1930 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1930/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1930/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1930/console Change summaries: 292559 by jhb: As previously noted in r290409, purge old entries from MAINTAINERS. 292558 by tuexen: Stop processing of a SACK when the association has been aborted. MFC after: 3 days 292557 by imp: Configure the Atmel eval boards to boot the same way. This gives them the same layout as other embedded systems. 292556 by ian: Add a mips implementation of OF_decode_addr(). 292555 by ian: Implement OF_decode_addr() for arm. Move most of powerpc's implementation into a new function that other platforms can share. This creates a new ofw_reg_to_paddr() function (in a new ofw_subr.c file) that contains most of the existing ppc implementation, mostly unchanged. The ppc code now calls the new MI code from the MD code, then creates a ppc-specific bus_space mapping from the results. The new arm implementation does the same in an arm-specific way. This also moves the declaration of OF_decode_addr() from ofw_machdep.h to openfirm.h, except on sparc64 which uses a different function signature. This will help all FDT platforms to set up early console access using OF_decode_addr(). The end of the build log: [...truncated 174129 lines...] cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/geom/geom_gate/../../../geom/gate/g_gate.c -o g_gate.o --- all_subdir_i2c --- ctfmerge -L VERSION -g -o intpm.kld intpm.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk intpm.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % intpm.kld --- intpm.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o intpm.ko.full intpm.o --- intpm.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug intpm.ko.full intpm.ko.debug --- intpm.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=intpm.ko.debug intpm.ko.full intpm.ko --- all_subdir_ismt --- ===> i2c/controllers/ismt (all) --- ismt.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/i2c/controllers/ismt/../../../../dev/ismt/ismt.c -o ismt.o --- all_subdir_geom --- --- all_subdir_geom_eli --- ctfconvert -L VERSION -g g_eli_integrity.o --- all_subdir_i2c --- --- all_subdir_iicbus --- ctfconvert -L VERSION -g iiconf.o --- iicbus.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/i2c/iicbus/../../../dev/iicbus/iicbus.c -o iicbus.o --- all_subdir_geom --- --- g_eli_privacy.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/geom/geom_eli/../../../geom/eli/g_eli_privacy.c -o g_eli_privacy.o --- all_subdir_i2c --- ctfconvert -L VERSION -g iicbus.o --- iicbus.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o iicbus.kld iicbus_if.o iiconf.o iicbus.o ctfmerge -L VERSION -g -o iicbus.kld iicbus_if.o iiconf.o iicbus.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk iicbus.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % iicbus.kld --- iicbus.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o iicbus.ko.full iicbus_if.o iiconf.o iicbus.o --- iicbus.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug iicbus.ko.full iicbus.ko.debug --- iicbus.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=iicbus.ko.debug iicbus.ko.full iicbus.ko --- all_subdir_controllers --- --- all_subdir_nfsmb --- ===> i2c/controllers/nfsmb (all) --- all_subdir_ismt --- ctfconvert -L VERSION -g ismt.o --- all_subdir_nfsmb --- --- nfsmb.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/i2c/controllers/nfsmb/../../../../dev/nfsmb/nfsmb.c -o nfsmb.o --- all_subdir_ismt --- --- ismt.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o ismt.kld ismt.o ctfmerge -L VERSION -g -o ismt.kld ismt.o --- all_subdir_geom --- ctfconvert -L VERSION -g g_eli_privacy.o --- all_subdir_i2c --- :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk ismt.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % ismt.kld --- ismt.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o ismt.ko.full ismt.o --- ismt.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug ismt.ko.full ismt.ko.debug --- ismt.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=ismt.ko.debug ismt.ko.full ismt.ko --- all_subdir_geom --- --- all_subdir_geom_gate --- ctfconvert -L VERSION -g g_gate.o --- exresnte.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/contrib/dev/acpica/components/executer/exresnte.c --- modules-all --- --- all_subdir_geom_eli --- --- geom_eli.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o geom_eli.kld g_eli.o g_eli_crypto.o g_eli_ctl.o g_eli_integrity.o g_eli_key.o g_eli_key_cache.o g_eli_privacy.o pkcs5v2.o --- all_subdir_geom_gate --- --- geom_gate.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o geom_gate.kld g_gate.o --- all_subdir_geom_eli --- ctfmerge -L VERSION -g -o geom_eli.kld g_eli.o g_eli_crypto.o g_eli_ctl.o g_eli_integrity.o g_eli_key.o g_eli_key_cache.o g_eli_privacy.o pkcs5v2.o --- all_subdir_geom_gate --- ctfmerge -L VERSION -g -o geom_gate.kld g_gate.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk geom_gate.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % geom_gate.kld --- geom_gate.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o geom_gate.ko.full g_gate.o --- geom_gate.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug geom_gate.ko.full geom_gate.ko.debug --- geom_gate.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=geom_gate.ko.debug geom_gate.ko.full geom_gate.ko --- all_subdir_i2c --- --- all_subdir_viapm --- ===> i2c/controllers/viapm (all) --- all_subdir_geom --- --- all_subdir_geom_eli --- :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk geom_eli.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % geom_eli.kld --- geom_eli.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o geom_eli.ko.full g_eli.o g_eli_crypto.o g_eli_ctl.o g_eli_integrity.o g_eli_key.o g_eli_key_cache.o g_eli_privacy.o pkcs5v2.o --- geom_eli.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug geom_eli.ko.full geom_eli.ko.debug --- all_subdir_i2c --- --- viapm.o --- --- all_subdir_geom --- --- geom_eli.ko --- --- all_subdir_i2c --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/i2c/controllers/viapm/../../../../dev/viapm/viapm.c -o viapm.o --- all_subdir_geom --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=geom_eli.ko.debug geom_eli.ko.full geom_eli.ko --- all_subdir_geom_journal --- ===> geom/geom_journal (all) --- exresnte.o --- ctfconvert -L VERSION -g exresnte.o --- modules-all --- --- all_subdir_i2c --- --- all_subdir_iicbb --- ===> i2c/iicbb (all) --- all_subdir_geom --- --- g_journal.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/geom/geom_journal/../../../geom/journal/g_journal.c -o g_journal.o --- all_subdir_i2c --- --- iicbb_if.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c iicbb_if.c -o iicbb_if.o --- all_subdir_controllers --- --- all_subdir_nfsmb --- ctfconvert -L VERSION -g nfsmb.o --- nfsmb.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o nfsmb.kld nfsmb.o ctfmerge -L VERSION -g -o nfsmb.kld nfsmb.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk nfsmb.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % nfsmb.kld --- nfsmb.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o nfsmb.ko.full nfsmb.o --- nfsmb.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug nfsmb.ko.full nfsmb.ko.debug --- nfsmb.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=nfsmb.ko.debug nfsmb.ko.full nfsmb.ko --- all_subdir_iicbb --- --- iicbb.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/i2c/iicbb/../../../dev/iicbus/iicbb.c -o iicbb.o --- iicbb_if.o --- ctfconvert -L VERSION -g iicbb_if.o --- all_subdir_if_disc --- ===> if_disc (all) --- if_disc.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/if_disc/../../net/if_disc.c -o if_disc.o --- all_subdir_i2c --- --- iicbb.o --- In file included from /usr/src/sys/modules/i2c/iicbb/../../../dev/iicbus/iicbb.c:56: In file included from /usr/src/sys/dev/ofw/ofw_bus.h:34: /usr/src/sys/dev/ofw/openfirm.h:177:47: error: unknown type name 'bus_space_tag_t'; did you mean 'bus_dma_tag_t'? int OF_decode_addr(phandle_t dev, int regno, bus_space_tag_t *ptag, ^~~~~~~~~~~~~~~ bus_dma_tag_t /usr/src/sys/sys/_bus_dma.h:43:29: note: 'bus_dma_tag_t' declared here typedef struct bus_dma_tag *bus_dma_tag_t; ^ In file included from /usr/src/sys/modules/i2c/iicbb/../../../dev/iicbus/iicbb.c:56: In file included from /usr/src/sys/dev/ofw/ofw_bus.h:34: /usr/src/sys/dev/ofw/openfirm.h:178:7: error: unknown type name 'bus_space_handle_t' bus_space_handle_t *phandle); ^ 2 errors generated. *** [iicbb.o] Error code 1 make[5]: stopped in /usr/src/sys/modules/i2c/iicbb 1 error make[5]: stopped in /usr/src/sys/modules/i2c/iicbb *** [all_subdir_iicbb] Error code 2 make[4]: stopped in /usr/src/sys/modules/i2c --- all_subdir_controllers --- --- all_subdir_viapm --- ctfconvert -L VERSION -g viapm.o A failure has been detected in another branch of the parallel make make[6]: stopped in /usr/src/sys/modules/i2c/controllers/viapm *** [all_subdir_viapm] Error code 2 make[5]: stopped in /usr/src/sys/modules/i2c/controllers 1 error make[5]: stopped in /usr/src/sys/modules/i2c/controllers *** [all_subdir_controllers] Error code 2 make[4]: stopped in /usr/src/sys/modules/i2c 2 errors make[4]: stopped in /usr/src/sys/modules/i2c *** [all_subdir_i2c] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_if_disc --- ctfconvert -L VERSION -g if_disc.o A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/if_disc *** [all_subdir_if_disc] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_geom --- ctfconvert -L VERSION -g g_journal.o A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/sys/modules/geom/geom_journal *** [all_subdir_geom_journal] Error code 2 make[4]: stopped in /usr/src/sys/modules/geom 1 error make[4]: stopped in /usr/src/sys/modules/geom *** [all_subdir_geom] 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/hudson3728577314387557202.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 Mon Dec 21 22:40: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 2ED96A4EA92 for ; Mon, 21 Dec 2015 22:40:25 +0000 (UTC) (envelope-from tom@snnap.net) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A66551782 for ; Mon, 21 Dec 2015 22:40:24 +0000 (UTC) (envelope-from tom@snnap.net) Received: by mail-lf0-x22f.google.com with SMTP id y184so118757715lfc.1 for ; Mon, 21 Dec 2015 14:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=snnap-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jU3MzGipV6wBYyuaZ4i84hgssqXV9w7Qpe53zQdY56g=; b=AIGx6zl5QIwK79ixsCMdDb8XEpdxXLaREq3+mJEh94/SSAMVtXko+vKkZtZ6BJ+7uV aFsrcjsby/unTDg4Z5oiglzEC3x8/2QTA5XKZvqJC3PVcx3TUzjk08V4M6nP4M7wegR2 KIJbItsF3CfDuaOTQjmzcSkCo3ELC3uDoAjjCitjtYW4CBB0OqV3A7/RBA55Ri18dVYM t3gZKntG2a8q+1yaxZXOToehvhA3YKmRW4WsWOHg4vyvfRZuI8L4rUtvjwQdmlUXNE5X eu2l7/mHDG70o7SVBXXfuanrKs+qn0/MX8Yg1OD/s7oY4edf2j6Dxwco93LUnWTfYTbV ldWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jU3MzGipV6wBYyuaZ4i84hgssqXV9w7Qpe53zQdY56g=; b=UAm6jk+/wAmrFyXHZp27TVmu0Brd3WtxuDXu3IeYFp/xlJDWN/gRHVVWXH3T2a5r8h ng827mrKawiKihxamA+R1ZHuBjzGplcBRGqT8j2q40rL3XKE4g9W5h/KfKkxjMxMLXHz CD4/7ROS1rr1WcxqxoOyC2G9yDVt1E+WoW2G7kxsDVX8zFqB/mWBFLHhe33HsjD/a8W8 m8njvrQPhOAg7EyKAI0Uh5hmmcGgic6Oqy30NTLGBihIUJ+QOnVsM/jYlcIMwmn3T9J4 4zZBCS3mwj6B60UGgT1RQXIcZI3vGDzUkCXwSbkTP2kM5HuwJppjCIcqKwmJVFF3Ovi0 gaaw== X-Gm-Message-State: ALoCoQnLBHMoxTXtX5bhBgNrh3D1Oh1/Il4KpPN6+Yq21Jl0Yi0UaqmzwwFsw1k9PSYx3lIsQ9EH+dUIp/HDfUAXmidGb/aVag== MIME-Version: 1.0 X-Received: by 10.25.167.197 with SMTP id q188mr7442894lfe.129.1450737622777; Mon, 21 Dec 2015 14:40:22 -0800 (PST) Received: by 10.112.25.73 with HTTP; Mon, 21 Dec 2015 14:40:22 -0800 (PST) X-Originating-IP: [2001:44b8:3164:6d12:850c:4f50:469:9980] In-Reply-To: <5677FB53.5000106@denninger.net> References: <5677FB53.5000106@denninger.net> Date: Tue, 22 Dec 2015 09:40:22 +1100 Message-ID: Subject: Re: 10.x stable/release for rpi 2? From: Tom Storey To: Karl Denninger 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: Mon, 21 Dec 2015 22:40:25 -0000 Got it. At least Im not blind. :-) On 22 December 2015 at 00:14, Karl Denninger wrote: > > On 12/21/2015 02:39, Tom Storey wrote: >> Sorry, I must be blind or something .. >> >> Are there any 10.x stable or release images for the rpi 2? >> >> I only see 11 current images for rpi 2, but I see 10.2 (where did 10.1 >> go?) stable for rpi B. >> >> Thanks! >> > There aren't any for the Rpi 2; at present only 11-Current is available > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ From owner-freebsd-arm@freebsd.org Mon Dec 21 22:56:58 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F8D5A4F2BB for ; Mon, 21 Dec 2015 22:56:58 +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 E3BFA13AD; Mon, 21 Dec 2015 22:56:57 +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 15E5FFE8; Mon, 21 Dec 2015 22:56:58 +0000 (UTC) Date: Mon, 21 Dec 2015 22:56:55 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: imp@FreeBSD.org, jlh@FreeBSD.org, gonzo@FreeBSD.org, ngie@FreeBSD.org, emaste@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <440922998.41.1450738618030.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1722782268.39.1450731425844.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1722782268.39.1450731425844.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1931 - 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: Mon, 21 Dec 2015 22:56:58 -0000 FreeBSD_HEAD_arm64 - Build #1931 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1931/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1931/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1931/console Change summaries: 292571 by gonzo: - Add driver for i.MX 6 HDMI framer - Enable HDMI driver in IMX6 config Reviewed by: andrew, ian, mmel Differential Revision: https://reviews.freebsd.org/D4174 292570 by ngie: Integrate tools/regression/mac/mac_bsdextended and tools/regression/mac/mac_portacl into the FreeBSD test suite as tests/sys/mac/bsdextended and tests/sys/mac/portacl, respectively MFC after: 1 month Sponsored by: EMC / Isilon Storage Division 292569 by ngie: Make the mac_portacl testcases work / more robust - A trap(1) call has been added to the test scripts to better ensure that the tests do a better job at trying to restore the test host state at the end of the tests (if the test was interrupted before it would leave the system in an odd state, potentially making the test results for subsequent runs non-deterministic). - Add root user checks - Fix nc(1) usage: -- -o is deprecated -- Using `-w 10` will make the call timeout after 10 seconds so it doesn't block indefinitely - Use local variables - Be more terse in the error messages - Parameterize out "127.0.0.1" MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 292567 by imp: Revert this change. It broke the trampoline build. Until I'm sure nothing else is broken, I'm reverting. 292565 by gonzo: Add CCM functions to enable HDMI framer and IPU units (video controller) Reviewed by: andrew, ian Differential Revision: https://reviews.freebsd.org/D4168 292564 by jlh: Add port for IRC over TLS/SSL, as noted in RFC 7194. PR: 192505 Submitted by: loic.blot@unix-experience.fr MFC after: 3 days 292563 by emaste: loader.efi: strip trailing whitespace Sponsored by: The FreeBSD Foundation The end of the build log: [...truncated 175467 lines...] /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug lpbb.ko.full lpbb.ko.debug --- lpbb.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=lpbb.ko.debug lpbb.ko.full lpbb.ko --- all_subdir_pcf --- ===> i2c/controllers/pcf (all) --- pcf.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/i2c/controllers/pcf/../../../../dev/pcf/pcf.c -o pcf.o --- all_subdir_geom --- ctfconvert -L VERSION -g g_mountver.o --- geom_mountver.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o geom_mountver.kld g_mountver.o ctfmerge -L VERSION -g -o geom_mountver.kld g_mountver.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk geom_mountver.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % geom_mountver.kld --- geom_mountver.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o geom_mountver.ko.full g_mountver.o --- geom_mountver.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug geom_mountver.ko.full geom_mountver.ko.debug --- geom_mountver.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=geom_mountver.ko.debug geom_mountver.ko.full geom_mountver.ko --- exfield.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/contrib/dev/acpica/components/executer/exfield.c ctfconvert -L VERSION -g exfield.o --- modules-all --- --- all_subdir_geom_multipath --- ===> geom/geom_multipath (all) --- all_subdir_i2c --- ctfconvert -L VERSION -g pcf.o --- pcf.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o pcf.kld pcf.o ctfmerge -L VERSION -g -o pcf.kld pcf.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk pcf.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % pcf.kld --- pcf.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o pcf.ko.full pcf.o --- pcf.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug pcf.ko.full pcf.ko.debug --- pcf.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=pcf.ko.debug pcf.ko.full pcf.ko --- all_subdir_geom --- --- g_multipath.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/geom/geom_multipath/../../../geom/multipath/g_multipath.c -o g_multipath.o --- all_subdir_i2c --- --- all_subdir_iicbus --- ===> i2c/iicbus (all) --- iicbus_if.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c iicbus_if.c -o iicbus_if.o ctfconvert -L VERSION -g iicbus_if.o --- iiconf.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/i2c/iicbus/../../../dev/iicbus/iiconf.c -o iiconf.o --- all_subdir_if_bridge --- ctfconvert -L VERSION -g if_bridge.o --- if_bridge.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o if_bridge.kld if_bridge.o ctfmerge -L VERSION -g -o if_bridge.kld if_bridge.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk if_bridge.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % if_bridge.kld --- if_bridge.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o if_bridge.ko.full if_bridge.o --- if_bridge.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug if_bridge.ko.full if_bridge.ko.debug --- if_bridge.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=if_bridge.ko.debug if_bridge.ko.full if_bridge.ko --- all_subdir_i2c --- --- iicbus.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/i2c/iicbus/../../../dev/iicbus/iicbus.c -o iicbus.o --- iiconf.o --- ctfconvert -L VERSION -g iiconf.o --- all_subdir_geom --- --- all_subdir_geom_nop --- ===> geom/geom_nop (all) --- g_nop.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/geom/geom_nop/../../../geom/nop/g_nop.c -o g_nop.o --- all_subdir_i2c --- --- iicbus.o --- ctfconvert -L VERSION -g iicbus.o --- iicbus.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o iicbus.kld iicbus_if.o iiconf.o iicbus.o ctfmerge -L VERSION -g -o iicbus.kld iicbus_if.o iiconf.o iicbus.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk iicbus.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % iicbus.kld --- all_subdir_geom --- --- all_subdir_geom_multipath --- ctfconvert -L VERSION -g g_multipath.o --- all_subdir_i2c --- --- iicbus.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o iicbus.ko.full iicbus_if.o iiconf.o iicbus.o --- all_subdir_geom --- --- geom_multipath.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o geom_multipath.kld g_multipath.o ctfmerge -L VERSION -g -o geom_multipath.kld g_multipath.o --- all_subdir_i2c --- --- iicbus.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug iicbus.ko.full iicbus.ko.debug --- all_subdir_geom --- :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk geom_multipath.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % geom_multipath.kld --- all_subdir_i2c --- --- iicbus.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=iicbus.ko.debug iicbus.ko.full iicbus.ko --- all_subdir_iicbb --- ===> i2c/iicbb (all) --- all_subdir_geom --- --- geom_multipath.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o geom_multipath.ko.full g_multipath.o --- geom_multipath.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug geom_multipath.ko.full geom_multipath.ko.debug --- geom_multipath.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=geom_multipath.ko.debug geom_multipath.ko.full geom_multipath.ko --- all_subdir_i2c --- --- all_subdir_iicsmb --- ===> i2c/iicsmb (all) --- all_subdir_iicbb --- --- iicbb_if.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c iicbb_if.c -o iicbb_if.o --- all_subdir_iicsmb --- --- iicsmb.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/i2c/iicsmb/../../../dev/iicbus/iicsmb.c -o iicsmb.o --- all_subdir_iicbb --- ctfconvert -L VERSION -g iicbb_if.o --- iicbb.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/i2c/iicbb/../../../dev/iicbus/iicbb.c -o iicbb.o --- all_subdir_geom --- --- all_subdir_geom_nop --- ctfconvert -L VERSION -g g_nop.o --- geom_nop.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o geom_nop.kld g_nop.o ctfmerge -L VERSION -g -o geom_nop.kld g_nop.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk geom_nop.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % geom_nop.kld --- geom_nop.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o geom_nop.ko.full g_nop.o --- geom_nop.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug geom_nop.ko.full geom_nop.ko.debug --- geom_nop.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=geom_nop.ko.debug geom_nop.ko.full geom_nop.ko --- all_subdir_if_edsc --- ===> if_edsc (all) --- all_subdir_i2c --- In file included from /usr/src/sys/modules/i2c/iicbb/../../../dev/iicbus/iicbb.c:56: In file included from /usr/src/sys/dev/ofw/ofw_bus.h:34: /usr/src/sys/dev/ofw/openfirm.h:177:47: error: unknown type name 'bus_space_tag_t'; did you mean 'bus_dma_tag_t'? int OF_decode_addr(phandle_t dev, int regno, bus_space_tag_t *ptag, ^~~~~~~~~~~~~~~ bus_dma_tag_t /usr/src/sys/sys/_bus_dma.h:43:29: note: 'bus_dma_tag_t' declared here typedef struct bus_dma_tag *bus_dma_tag_t; ^ In file included from /usr/src/sys/modules/i2c/iicbb/../../../dev/iicbus/iicbb.c:56: In file included from /usr/src/sys/dev/ofw/ofw_bus.h:34: /usr/src/sys/dev/ofw/openfirm.h:178:7: error: unknown type name 'bus_space_handle_t' bus_space_handle_t *phandle); ^ --- all_subdir_iicsmb --- ctfconvert -L VERSION -g iicsmb.o --- all_subdir_if_edsc --- --- if_edsc.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -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 -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 -c /usr/src/sys/modules/if_edsc/../../net/if_edsc.c -o if_edsc.o --- all_subdir_i2c --- --- iicsmb.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o iicsmb.kld iicsmb.o ctfmerge -L VERSION -g -o iicsmb.kld iicsmb.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk iicsmb.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % iicsmb.kld --- all_subdir_iicbb --- 2 errors generated. *** [iicbb.o] Error code 1 make[5]: stopped in /usr/src/sys/modules/i2c/iicbb 1 error make[5]: stopped in /usr/src/sys/modules/i2c/iicbb *** [all_subdir_iicbb] Error code 2 make[4]: stopped in /usr/src/sys/modules/i2c --- all_subdir_iicsmb --- A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/sys/modules/i2c/iicsmb *** [all_subdir_iicsmb] Error code 2 make[4]: stopped in /usr/src/sys/modules/i2c 2 errors make[4]: stopped in /usr/src/sys/modules/i2c *** [all_subdir_i2c] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_if_edsc --- ctfconvert -L VERSION -g if_edsc.o A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/if_edsc *** [all_subdir_if_edsc] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_geom --- --- all_subdir_geom_mirror --- ctfconvert -L VERSION -g g_mirror.o A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/sys/modules/geom/geom_mirror *** [all_subdir_geom_mirror] Error code 2 make[4]: stopped in /usr/src/sys/modules/geom 1 error make[4]: stopped in /usr/src/sys/modules/geom *** [all_subdir_geom] 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/hudson7474188134336236834.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 Tue Dec 22 01:00:18 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CED019D5C55 for ; Tue, 22 Dec 2015 01:00:18 +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 C27E61DED; Tue, 22 Dec 2015 01:00:18 +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 D31D910E0; Tue, 22 Dec 2015 01:00:18 +0000 (UTC) Date: Tue, 22 Dec 2015 01:00:15 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: gonzo@FreeBSD.org, asomers@FreeBSD.org, ian@FreeBSD.org, emaste@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <823739226.43.1450746018738.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <440922998.41.1450738618030.JavaMail.jenkins@jenkins-9.freebsd.org> References: <440922998.41.1450738618030.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1932 - 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: Tue, 22 Dec 2015 01:00:18 -0000 FreeBSD_HEAD_arm64 - Build #1932 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1932/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1932/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1932/console Change summaries: 292577 by ian: Include machine/_bus.h so that bus_space_[tag|handle]_t will be available. It appears that all platforms except aarch64 are getting the file via various header pollution, and ensuring _bus.h is included before any openfirmware headers in every consumer of ofw/fdt stuff seems like more of a career path than a task, so I'm taking this easy way out. 292576 by emaste: boot1.efi: show EFI error number, not full status value EFI return values set the high bit to indicate an error. The log messages changed here are printed only in the case of an error, so including the error bit is redundant. Also switch to decimal to match the error definitions (in sys/boot/efi/include/efierr.h). MFC after: 1 week Sponsored by: The FreeBSD Foundation 292575 by emaste: rtld: Use common NT_FREEBSD_* note types introduced in r291909 Sponsored by: The FreeBSD Foundation 292574 by gonzo: Add i.MX 6 IPU driver and enable it in IMX6 config Current functionality is somewhat limited: driver assumes that there is only one active IPU unit (IPU1) and that video output is DI0 and video mode is 1024x768. For more advanced functionality driver requires proper clock management which is work in progress. At the moment driver assumes that pixel clock is configured by u-boot for 1026x768 mode. Reviewed by: andrew, ian, mmel Differential Revision: https://reviews.freebsd.org/D4168 292573 by asomers: Fix "mount -a" for NFS and ZFS filesystems with shared mountpoints sbin/mount.c Check whether an fstab entry has the same fstype as a mounted filesystem before declaring it to be mounted. This will allow NFS filesystems that share a mountpoint with a local filesystem to be automatically mounted at boot. This is not such an unusual situation. For example, if somebody uses the standard installer with a ZFS root, he'll get a /usr/home filesystem, even though he may choose to mount /usr/home over NFS. Reviewed by: trasz MFC after: 4 weeks Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D4556 From owner-freebsd-arm@freebsd.org Tue Dec 22 03:48: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 DA330A4C159 for ; Tue, 22 Dec 2015 03:48:59 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65A8C17E0 for ; Tue, 22 Dec 2015 03:48:59 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id p187so93969250wmp.0 for ; Mon, 21 Dec 2015 19:48:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=dIaqdr+FqTwKxw9thbQe9hzK6u9eRjqxWR9HDrLrDro=; b=ISBopy0/V+gJiFIOZyGzfM25lNozWpsoh8XY5fKAXuDAhQJ7UmVQ6t+Q+bLyVvIx7N gun52PeLurI7mviSLDmgwB5r13bu1hE9/hJniuB9CEzaERemU1wFuz4vwoERfOxCbBGm aeYTTDX0I6Hon5TqNOiX9xRk8xONLiQtVblWRih2djZkiHb8Is1ST+spXok3wPw+k58q lG+2T5SDxtPEIt5Wicqg4yfuUqp2XFZzHqVzdUN6Z/VHKP8erSKxZbxtKpslSOKDvSDT DtrTZYvXVvm+ijQ8UA9pmYawsxNjVFm/AyN5EAgjKzfvtLDlvxi/xr5/+QrRugfvV9lL rAbQ== X-Received: by 10.194.236.6 with SMTP id uq6mr24535736wjc.126.1450756137746; Mon, 21 Dec 2015 19:48:57 -0800 (PST) Received: from [192.168.0.5] (lns-bzn-50f-81-56-235-196.adsl.proxad.net. [81.56.235.196]) by smtp.gmail.com with ESMTPSA id 198sm22896336wmr.18.2015.12.21.19.48.56 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Dec 2015 19:48:56 -0800 (PST) From: Sylvain Garrigues Subject: Booting the ELF kernel without ubldr on Raspberry Pi Message-Id: Date: Tue, 22 Dec 2015 04:48:55 +0100 To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) 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, 22 Dec 2015 03:48:59 -0000 Hello, I=E2=80=99d like to boot FreeBSD directly with u-boot, without ubldr, = using an image provided by the u-boot mkimage tool. The reason is = simple: mkimage can deal with compressed kernels and will therefore = speed my boot time. And I want to try it anyway, as it seems possible = reading = http://bsdcan.org/2008/schedule/attachments/49_2008_uboot_freebsd.pdf = = and various other=20 Before going there and using an mkimage, I=E2=80=99d like to boot the = kernel image just with the same bootelf version provided by the = sysutils/u-boot-rpi2 port. It doesn=E2=80=99t display anything and = crashes (I think I can see =C2=AB illegal instruction =C2=BB just before = the board reboots). I don=E2=80=99t understand why, and this is my first = question. Then I looked at the mkimage utility, although we can specify and = freebsd kernel type through the -O flag, the bootm command only = understands linux and NetBSD. I guess I should use linux there? Thanks for your help, Sylvain PS: FYI, below is: 1/ info about my kernel (I can see the entry point is at 0xc0100100), = copied into the fat partition # readelf -h = /root/crochet/work/obj/arm.armv6/root/crochet/src/sys/RPI2/kernel = =20 ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00=20 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: ARM Version: 0x1 Entry point address: 0xc0100100 Start of program headers: 52 (bytes into file) Start of section headers: 6235080 (bytes into file) Flags: 0x5000202, has entry point, = Version5 EABI, Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 6 Size of section headers: 40 (bytes) Number of section headers: 38 Section header string table index: 35 [root@clad /usr/ports/sysutils/u-boot-rpi2]# =20 2/ the interesting part of my include/configs/rpi-common.h from u-boot: #define CONFIG_EXTRA_ENV_SETTINGS \ ENV_DEVICE_SETTINGS \ "loadaddr=3D0x02000000\0" \ "Fatboot=3D" \ "env exists loaderdev || env set loaderdev ${fatdev}; " \ "echo Booting from: ${fatdev} ${bootfile}; " \ "fatload ${fatdev} ${loadaddr} ${bootfile} && bootelf = ${loadaddr}; " \ "\0" \ "preboot=3D" \ "fdt addr 0x100; " \ "env set bootfile kernel; " \ =20 "env set fatdev 'mmc 0'; " \ "\0" #undef CONFIG_BOOTCOMMAND #define CONFIG_BOOTCOMMAND "run Fatboot" #undef CONFIG_PREBOOT #define CONFIG_PREBOOT "run preboot"= From owner-freebsd-arm@freebsd.org Tue Dec 22 15:23: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 AEAB5A4F4E4 for ; Tue, 22 Dec 2015 15:23:52 +0000 (UTC) (envelope-from bsz@semihalf.com) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002: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 749F31155 for ; Tue, 22 Dec 2015 15:23:52 +0000 (UTC) (envelope-from bsz@semihalf.com) Received: by mail-yk0-x236.google.com with SMTP id 140so166805197ykp.0 for ; Tue, 22 Dec 2015 07:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=BMDXX5gtEt4RcJmPCPGFu+SjXhvP2bgsXzDhM00GBZc=; b=OlRYVhuSfE5UVRNmGFitsUqVlmMwu48PasFzlYhcbmTgq8Z0Um0ryX80zJEsLMjv6p dmW9hMzDd5afrS230K/0rVwwm6wRme/GQQ+Vd7OgN7e+Z8fE6XXtINHmEj1m232O1Xk0 qgjrOibj6F3ClTDu3PS4Tsmq2g7fmKeHOUpyle2sdAmn3Fgv6AcdKjN73u0EeNdwHynf fVw5sn7ozzQCPXLA3NDw/E8tYyB3S5bWp63sh1I7M2PNeEkr/3OqpI2lJh2/FsDYaWwZ 3Yn5yPbNDzyD6aTQaU7RN+PBcGLbVzgA0TafDsiP6dPFW4GzoKOAiGDoQuhQrAH5kxW3 2nIg== 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:cc :content-type; bh=BMDXX5gtEt4RcJmPCPGFu+SjXhvP2bgsXzDhM00GBZc=; b=CrgwfXhHwTDthiftRKyLv118F4Ilv9s/wsKHsCylL5p8fzL7h4QLouGORjYG3fJYNJ Oueylj0cWjw+fSYhHqyU0gobyrmOTf9mJ9/ZAJoADOWKrrAdc9r3c3Ar0lGmjgtt63Zl lKN6PorHU7Ce68DM7vY6mtC06zVq4JDy/uX6QzdCJHNwPqsWW1g6cuwyjsEGbB8q1By5 5GppwpY+DjxkwHOUj+9r6VB1aS55NuU2/cpLQhFmitZTw3dW+SNRC85FhI8E3IU4oZaI JNOh6QSsAGcDlb6sAB3NGFMxFbUZ4MFc6uMfQTUwzVEv/5umJqliihgwSqIolK6HwvaF sjRg== X-Gm-Message-State: ALoCoQl5eaPlOFLvECUPXn4pYSId7eqQ99FvvSVTX97CnsMsS4bTsRY4xWB5RO/iIxRG4I2AiuJPUP3K4UGLCwxki5yxn+PHqA== MIME-Version: 1.0 X-Received: by 10.13.227.130 with SMTP id m124mr19249114ywe.215.1450797831313; Tue, 22 Dec 2015 07:23:51 -0800 (PST) Received: by 10.13.208.69 with HTTP; Tue, 22 Dec 2015 07:23:51 -0800 (PST) Date: Tue, 22 Dec 2015 16:23:51 +0100 Message-ID: Subject: Translation Fault (L1) while using pmap-v6-new From: Bartosz Szczepanek To: freebsd-arm@freebsd.org, skra@freebsd.org Cc: Marcin Wojtas Content-Type: multipart/mixed; boundary=94eb2c0773ec60b22605277e31ba 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, 22 Dec 2015 15:23:52 -0000 --94eb2c0773ec60b22605277e31ba Content-Type: text/plain; charset=UTF-8 Hello, currently I'm working on support for Armada38x on FreeBSD-CURRENT (patchset was submitted to Phabricator - https://reviews.freebsd.org/D4210). After switching to ARM_NEW_PMAP problems related with PCIe subsystem emerged, even though that worked fine on FreeBSD-10.2. My setup consists of Marvell Armada38x GP development board equipped with Cortex-A9, PCIe controller serviced by arm/mv/mv_pci.c driver and RealTek GE PCI card (re driver). Enabling ARM_NEW_PMAP leads to 'Translation Fault (L1)' on write: > Starting Network: lo0 re0. > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > re0: flags=8802 metrnelric 0 mtu 1500 > mod options=8209b aN_MTU,VLAN_HWTAGbortGING,VLAN_HWCSUM: 'T,WOL_MAGIC,LINKSransTATE> > on F ether 64lati:70:02:10:f7:20 > ault (L1)' on write > trapframe: 0xefe78b40 > FSR=00000805, FAR=80000060, spsr=60000013 > r0 =c0e796c0, r1 =80000000, r2 =00000004, r3 =00010000 > r4 =c57f1000, r5 =c57f1000, r6 =00000000, r7 =00000001 > r8 =c0e47e8c, r9 =c5be3780, r10=c57efb00, r11=efe78be0 > r12=efe78d43, ssp=efe78bd0, slr=c0971ef4, pc =c0971f64 > [ thread pid 241 tid 100068 ] > Stopped at re_gmii_readreg+0x50: str r3, [r1, #0x060] > db> (re_gmii_readreg is function in re driver, I made it non-static so it is visible in debugger) Address it crashes on lies in the PCI devices' memory range, and it was accessed successfully several times during boot proccess before crash (I put printfs in the exact function where fault occurs). So it seems just like the memory mapping has disappeared at some point. I put kdb_enter in re attach function (long before translation fault), from that point I see that 0x80000000 mapping exists: > pcib0: mem 0xf1080000-0xf1081fff irq 1 on ofwbus0 > [ thread pid 0 tid 100000 ] > Stopped at kdb_enter+0x58: ldrb r15, [r15, r15, ror r15]! > db> show pmap > pmap: 0xC0EAC544 > PT2MAP: 0xBFC00000 > pt2tab: 0xC0F04000 > 0x80000000: Section 0x8001041A, s:1 g:1 > 0x80100000: Section 0x8011041A, s:1 g:1 > 0x80200000: Section 0x8021041A, s:1 g:1 > 0x80300000: Section 0x8031041A, s:1 g:1 > ... Doing 'show pmap' after crash gives me long, long log without 0x80000000 occuring. On the other hand, adding vtophys(0x80000060) line before affected write operation translates address correctly. It is visible in log attached. I've also tried to track various functions removing mapping in pmap-v6-new, but with no luck. However, problem seems to lie there, as system boots fine without ARM_NEW_PMAP option. I would be grateful for you advice - what else can I do to investigate the issue? Best regards, Bartosz Szczepanek --94eb2c0773ec60b22605277e31ba Content-Type: text/plain; charset=US-ASCII; name="pmap_a38x_log.txt" Content-Disposition: attachment; filename="pmap_a38x_log.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iihj89ga0 IyMgU3RhcnRpbmcgYXBwbGljYXRpb24gYXQgMHgwMDkwMDAwMCAuLi4KS0RCOiBkZWJ1Z2dlciBi YWNrZW5kczogZGRiCktEQjogY3VycmVudCBiYWNrZW5kOiBkZGIKQ29weXJpZ2h0IChjKSAxOTky LTIwMTUgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgz LCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVnZW50cyBv ZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVl QlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4K RnJlZUJTRCAxMS4wLUNVUlJFTlQgIzE5MSAzOGIzMDAzKGRldmVsLWZic2QtYTM4eC1ic3otdXBz dHJlYW0pLWRpcnR5OiBUdWUgRGVjIDIyIDE1OjU5OjUwIENFVCAyMDE1CiAgICBic3pAZmJzZDov dXNyL2hvbWUvYnN6L2J1aWxkL2FybS5hcm12Ni91c3IvaG9tZS9ic3ovZnJlZWJzZC1uZXRhc3Ev c3lzL0FSTUFEQTM4WCBhcm0KRnJlZUJTRCBjbGFuZyB2ZXJzaW9uIDMuNy4wICh0YWdzL1JFTEVB U0VfMzcwL2ZpbmFsIDI0NjI1NykgMjAxNTA5MDYKQ1BVOiBDb3J0ZXggQTktcjQgcmV2IDEgKENv cnRleC1BIGNvcmUpCiBTdXBwb3J0ZWQgZmVhdHVyZXM6IEFSTV9JU0EgVEhVTUIyIEpBWkVMTEUg VEhVTUJFRSBBUk12NCBTZWN1cml0eV9FeHQKIFdCIGRpc2FibGVkIEVBQlQgYnJhbmNoIHByZWRp Y3Rpb24gZW5hYmxlZApMb1VVOjIgTG9DOjIgTG9VSVM6MiAKQ2FjaGUgbGV2ZWwgMTogCiAzMktC LzMyQiA0LXdheSBkYXRhIGNhY2hlIFdCIFJlYWQtQWxsb2MgV3JpdGUtQWxsb2MKIDMyS0IvMzJC IDQtd2F5IGluc3RydWN0aW9uIGNhY2hlIFJlYWQtQWxsb2MKcmVhbCBtZW1vcnkgID0gMjE0NzQ3 OTU1MiAoMjA0NyBNQikKYXZhaWwgbWVtb3J5ID0gMjA5NTcyMjQ5NiAoMTk5OCBNQikKU09DOiBN YXJ2ZWxsIDg4RjY4MjgsIFRDbG9jayAyNTBNSHoKICBJbnN0cnVjdGlvbiBjYWNoZSBwcmVmZXRj aCBlbmFibGVkLCBkYXRhIGNhY2hlIHByZWZldGNoIGRpc2FibGVkCkZyZWVCU0QvU01QOiBNdWx0 aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDIgQ1BVcwpyYW5kb206IGVudHJvcHkgZGV2aWNl IGV4dGVybmFsIGludGVyZmFjZQpvZndidXMwOiA8T3BlbiBGaXJtd2FyZSBEZXZpY2UgVHJlZT4K c2ltcGxlYnVzMDogPEZsYXR0ZW5lZCBkZXZpY2UgdHJlZSBzaW1wbGUgYnVzPiBvbiBvZndidXMw CnNpbXBsZWJ1czE6IDxGbGF0dGVuZWQgZGV2aWNlIHRyZWUgc2ltcGxlIGJ1cz4gb24gc2ltcGxl YnVzMApnaWMwOiA8QVJNIEdlbmVyaWMgSW50ZXJydXB0IENvbnRyb2xsZXI+IG1lbSAweGQwMDAt MHhkZmZmLDB4YzEwMC0weGMxZmYgb24gc2ltcGxlYnVzMQpnaWMwOiBwbiAweDM5MCwgYXJjaCAw eDEsIHJldiAweDIsIGltcGxlbWVudGVyIDB4NDNiIGlycXMgMTkyCm1waWMwOiA8TWFydmVsbCBJ bnRlZ3JhdGVkIEludGVycnVwdCBDb250cm9sbGVyPiBtZW0gMHgyMGEwMC0weDIwY2NmLDB4MjEw MDAtMHgyMTBmZiwweDIwNDAwLTB4MjA0ZmYgaXJxIDE4IG9uIHNpbXBsZWJ1czEKbXBfdG1yMDog PEFSTSBNUENvcmUgVGltZXJzPiBtZW0gMHhjMjAwLTB4YzIxZiBpcnEgMiBvbiBzaW1wbGVidXMx ClRpbWVjb3VudGVyICJNUENvcmUiIGZyZXF1ZW5jeSA4MDAwMDAwMDAgSHogcXVhbGl0eSA4MDAK bXBfdG1yMTogPEFSTSBNUENvcmUgVGltZXJzPiBtZW0gMHhjNjAwLTB4YzYxZiBpcnEgMyBvbiBz aW1wbGVidXMxCkV2ZW50IHRpbWVyICJNUENvcmUiIGZyZXF1ZW5jeSA4MDAwMDAwMDAgSHogcXVh bGl0eSAxMDAwCnR3c2kwOiA8TWFydmVsbCBJbnRlZ3JhdGVkIEkyQyBCdXMgQ29udHJvbGxlcj4g bWVtIDB4MTEwMDAtMHgxMTAxZiBpcnEgNiBvbiBzaW1wbGVidXMxCmlpY2J1czA6IDxQaGlsaXBz IEkyQyBidXM+IG9uIHR3c2kwCmlpYzA6IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1czAKdWFy dDA6IDwxNjU1MCBvciBjb21wYXRpYmxlPiBtZW0gMHgxMjAwMC0weDEyMGZmIGlycSA4IG9uIHNp bXBsZWJ1czEKdWFydDA6IGNvbnNvbGUgKDg1MyxuLDgsMSkKdGltZXIwOiA8TWFydmVsbCBDUFUg VGltZXI+IG1lbSAweDIwMzAwLTB4MjAzMzMsMHgyMDcwNC0weDIwNzA3LDB4MTgyNjAtMHgxODI2 MyBvbiBzaW1wbGVidXMxCnRpbWVyMDogb25seSB3YXRjaGRvZyBhdHRhY2hlZApwbXN1MDogPFBv d2VyIE1hbmFnZW1lbnQgU2VydmljZSBVbml0PiBtZW0gMHgyMjAwMC0weDIyZmZmIG9uIHNpbXBs ZWJ1czEKZWhjaTA6IDxNYXJ2ZWxsIEludGVncmF0ZWQgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0g MHg1ODAwMC0weDU4NGZmIGlycSAyNyBvbiBzaW1wbGVidXMxCnVzYnVzMDogRUhDSSB2ZXJzaW9u IDEuMAp1c2J1czA6IHNldCBob3N0IGNvbnRyb2xsZXIgbW9kZQp1c2J1czAgb24gZWhjaTAKcnRj MDogPE1hcnZlbGwgSW50ZWdyYXRlZCBSVEM+IG1lbSAweGEzODAwLTB4YTM4MWYsMHgxODRhMC0w eDE4NGFiIGlycSAyOSBvbiBzaW1wbGVidXMxCnhoY2kwOiA8TWFydmVsbCBJbnRlZ3JhdGVkIFVT QiAzLjAgY29udHJvbGxlcj4gbWVtIDB4ZjAwMDAtMHhmM2ZmZiwweGY0MDAwLTB4ZjdmZmYgaXJx IDM0IG9uIHNpbXBsZWJ1czEKeGhjaTA6IDMyIGJ5dGVzIGNvbnRleHQgc2l6ZSwgMzItYml0IERN QQp1c2J1czEgb24geGhjaTAKeGhjaTE6IDxNYXJ2ZWxsIEludGVncmF0ZWQgVVNCIDMuMCBjb250 cm9sbGVyPiBtZW0gMHhmODAwMC0weGZiZmZmLDB4ZmMwMDAtMHhmZmZmZiBpcnEgMzUgb24gc2lt cGxlYnVzMQp4aGNpMTogMzIgYnl0ZXMgY29udGV4dCBzaXplLCAzMi1iaXQgRE1BCnVzYnVzMiBv biB4aGNpMQpwY2liMDogPE1hcnZlbGwgSW50ZWdyYXRlZCBQQ0kvUENJLUUgQ29udHJvbGxlcj4g bWVtIDB4ZjEwODAwMDAtMHhmMTA4MWZmZiBpcnEgMSBvbiBvZndidXMwClsgdGhyZWFkIHBpZCAw IHRpZCAxMDAwMDAgXQpTdG9wcGVkIGF0ICAgICAga2RiX2VudGVyKzB4NTg6IGxkcmIgICAgcjE1 LCBbcjE1LCByMTUsIHJvciByMTVdIQpkYj4gYwpwY2kwOiA8UENJIGJ1cz4gb24gcGNpYjAKcmUw OiA8UmVhbFRlayA4MTY4LzgxMTEgQi9DL0NQL0QvRFAvRS9GL0cgUENJZSBHaWdhYml0IEV0aGVy bmV0PiBwb3J0IDB4ODEwMDAwMDAtMHg4MTAwMDBmZiBtZW0gMHg4MDAwMDAwMC0weDgwMDAwZmZm LDB4ODAwMDQwMDAtMHg4MDAwN2ZmZiBhdCBkZXZpY2UgMC4wIG9uIHBjaTAKcmUwOiBDaGlwIHJl di4gMHgyYzAwMDAwMApyZTA6IE1BQyByZXYuIDB4MDAyMDAwMDAKdnRvcGh5czogMHg4MDAwMDA2 MAp2dG9waHlzOiAweDgwMDAwMDYwCnZ0b3BoeXM6IDB4ODAwMDAwNjAKbWlpYnVzMDogPE1JSSBi dXM+IG9uIHJlMAp1a3BoeTA6IDxHZW5lcmljIElFRUUgODAyLjN1IG1lZGlhIGludGVyZmFjZT4g UEhZIDEgb24gbWlpYnVzMAp2dG9waHlzOiAweDgwMDAwMDYwCnZ0b3BoeXM6IDB4ODAwMDAwNjAK dnRvcGh5czogMHg4MDAwMDA2MAp2dG9waHlzOiAweDgwMDAwMDYwCnZ0b3BoeXM6IDB4ODAwMDAw NjAKdnRvcGh5czogMHg4MDAwMDA2MAp1a3BoeTA6ICBub25lLCAxMGJhc2VULCAxMGJhc2VULUZE WCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1tYXN0ZXIs IDEwMDBiYXNlVC1GRFgsIDEwMDBiYXNlVC1GRFgtbWFzdGVyLCBhdXRvLCBhdXRvLWZsb3cKdnRv cGh5czogMHg4MDAwMDA2MApyZTA6IFVzaW5nIGRlZmF1bHRzIGZvciBUU086IDY1NTE4LzM1LzIw NDgKcmUwOiBFdGhlcm5ldCBhZGRyZXNzOiA2NDo3MDowMjoxMDpmNzoyMApjcnlwdG9zb2Z0MDog PHNvZnR3YXJlIGNyeXB0bz4KVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMTAuMDAwIG1zZWMKSVBz ZWM6IEluaXRpYWxpemVkIFNlY3VyaXR5IEFzc29jaWF0aW9uIFByb2Nlc3NpbmcuCnVzYnVzMDog NDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVzYnVzMTogNS4wR2JwcyBTdXBlciBTcGVlZCBV U0IgdjMuMAp1c2J1czI6IDUuMEdicHMgU3VwZXIgU3BlZWQgVVNCIHYzLjAKU3dhcCB6b25lIGVu dHJpZXMgcmVkdWNlZCBmcm9tIDI1NjE2OSB0byAxNzA3NzkuClJlbGVhc2UgQVBzCm1vdW50cm9v dDogaW52YWxpZCBmaWxlIHN5c3RlbSBzcGVjaWZpY2F0aW9uLgoKTG9hZGVyIHZhcmlhYmxlczoK Ck1hbnVhbCByb290IGZpbGVzeXN0ZW0gc3BlY2lmaWNhdGlvbjoKICA8ZnN0eXBlPjo8ZGV2aWNl PiBbb3B0aW9uc10KICAgICAgTW91bnQgPGRldmljZT4gdXNpbmcgZmlsZXN5c3RlbSA8ZnN0eXBl PgogICAgICBhbmQgd2l0aCB0aGUgc3BlY2lmaWVkIChvcHRpb25hbCkgb3B0aW9uIGxpc3QuCgog ICAgZWcuIHVmczovZGV2L2RhMHMxYQogICAgICAgIHpmczp0YW5rCiAgICAgICAgY2Q5NjYwOi9k ZXYvY2QwIHJvCiAgICAgICAgICAod2hpY2ggaXMgZXF1aXZhbGVudCB0bzogbW91bnQgLXQgY2Q5 NjYwIC1vIHJvIC9kZXYvY2QwIC8pCgogID8gICAgICAgICAgICAgICBMaXN0IHZhbGlkIGRpc2sg Ym9vdCBkZXZpY2VzCiAgLiAgICAgICAgICAgICAgIFlpZWxkIDEgc2Vjb25kIChmb3IgYmFja2dy b3VuZCB0YXNrcykKICA8ZW1wdHkgbGluZT4gICAgQWJvcnQgbWFudWFsIGlucHV0Cgptb3VudHJv b3Q+IC4KdWdlbjEuMTogPE1hcnZlbGw+IGF0IHVzYnVzMQp1Z2VuMi4xOiA8TWFydmVsbD4gYXQg dXNidXMyCnVodWIwOiA8TWFydmVsbCBYSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAzLjAw LzEuMDAsIGFkZHIgMT4gb24gdXNidXMxCnVodWIxOiA8TWFydmVsbCBYSENJIHJvb3QgSFVCLCBj bGFzcyA5LzAsIHJldiAzLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMyCnVnZW4wLjE6IDxNYXJ2 ZWxsPiBhdCB1c2J1czAKdWh1YjI6IDxNYXJ2ZWxsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwg cmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czAKdWh1YjE6IDIgcG9ydHMgd2l0aCAyIHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNl bGYgcG93ZXJlZAp1aHViMjogMSBwb3J0IHdpdGggMSByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAoK bW91bnRyb290PiBnaWMwOiBTcHVyaW91cyBpbnRlcnJ1cHQgZGV0ZWN0ZWQ6IGxhc3QgaXJxOiAy OSBvbiBDUFUwCi4KCm1vdW50cm9vdD4gLgp1Z2VuMC4yOiA8dmVuZG9yIDB4MDkzMD4gYXQgdXNi dXMwCnVtYXNzMDogPHZlbmRvciAweDA5MzAgVVNCIEZsYXNoIE1lbW9yeSwgY2xhc3MgMC8wLCBy ZXYgMi4wMC8xLjAwLCBhZGRyIDI+IG9uIHVzYnVzMApkYTAgYXQgdW1hc3Mtc2ltMCBidXMgMCBz Y2J1czAgdGFyZ2V0IDAgbHVuIDAKZGEwOiA8IFVTQiBGbGFzaCBNZW1vcnkgMS4wMD4gUmVtb3Zh YmxlIERpcmVjdCBBY2Nlc3MgU1BDLTIgU0NTSSBkZXZpY2UKZGEwOiBTZXJpYWwgTnVtYmVyIEND NTJBRjRDODI0NENFQzBEMjlCQTMxQgpkYTA6IDQwLjAwME1CL3MgdHJhbnNmZXJzCmRhMDogNzM5 Nk1CICgxNTE0ODYwOCA1MTIgYnl0ZSBzZWN0b3JzKQpkYTA6IHF1aXJrcz0weDI8Tk9fNl9CWVRF PgoKbW91bnRyb290PiB1ZnM6ZGEwczFhClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOmRh MHMxYSBbXS4uLgpTZXR0aW5nIGhvc3R1dWlkOiA3NmM2M2M1ZC01YWY4LTExZTUtYmExMy0yOTNm ZDZkMjAwNTAuClNldHRpbmcgaG9zdGlkOiAweDIwMjU3YjgzLgpFbnRyb3B5IGhhcnZlc3Rpbmc6 c3lzY3RsOiB1bmtub3duIG9pZCAna2Vybi5yYW5kb20uc3lzLmhhcnZlc3QuaW50ZXJydXB0Jzog Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQogaW50ZXJydXB0c3N5c2N0bDogdW5rbm93biBvaWQg J2tlcm4ucmFuZG9tLnN5cy5oYXJ2ZXN0LmV0aGVybmV0JzogTm8gc3VjaCBmaWxlIG9yIGRpcmVj dG9yeQogZXRoZXJuZXRzeXNjdGw6IHVua25vd24gb2lkICdrZXJuLnJhbmRvbS5zeXMuaGFydmVz dC5wb2ludF90b19wb2ludCc6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKIHBvaW50X3RvX3Bv aW50c3lzY3RsOiB1bmtub3duIG9pZCAna2Vybi5yYW5kb20uc3lzLmhhcnZlc3Quc3dpJzogTm8g c3VjaCBmaWxlIG9yIGRpcmVjdG9yeQogc3dpLgpTdGFydGluZyBmaWxlIHN5c3RlbSBjaGVja3M6 Ci9kZXYvZGEwczFhOiBGSUxFIFNZU1RFTSBDTEVBTjsgU0tJUFBJTkcgQ0hFQ0tTCi9kZXYvZGEw czFhOiBjbGVhbiwgNDEyOTAxIGZyZWUgKDI2OSBmcmFncywgNTE1NzkgYmxvY2tzLCAwLjAlIGZy YWdtZW50YXRpb24pCk1vdW50aW5nIGxvY2FsIGZpbGUgc3lzdGVtczouCnJhbmRvbTogdW5ibG9j a2luZyBkZXZpY2UuCldyaXRpbmcgZW50cm9weSBmaWxlOi4KU2V0dGluZyBob3N0bmFtZTogYTM4 eC4KU3RhcnRpbmcgTmV0d29yazogbG8wIHJlMC4KbG8wOiBmbGFncz04MDQ5PFVQLExPT1BCQUNL LFJVTk5JTkcsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTYzODQKCW9wdGlvbnM9NjAwMDAzPFJY Q1NVTSxUWENTVU0sUlhDU1VNX0lQVjYsVFhDU1VNX0lQVjY+CglpbmV0NiA6OjEgcHJlZml4bGVu IDEyOCAKCWluZXQ2IGZlODA6OjElbG8wIHByZWZpeGxlbiA2NCBzY29wZWlkIDB4MiAKCWluZXQg MTI3LjAuMC4xIG5ldG1hc2sgMHhmZjAwMDAwMCAKCW5kNiBvcHRpb25zPTIxPFBFUkZPUk1OVUQs QVVUT19MSU5LTE9DQUw+CnJlMDogZmxhZ3M9ODgwMjx2dG9wQlJPQURDQVNULFNJTVBMRWh5czpY LE1VTFRJQ0FTVD4gbWV0IDB4OHJpYyAwIG10dSAxNTAwClhDU1VNLFRYQ1NVTSxWTEE4MjA5YjxS MDYwCiAgICAgICAgICAgICAgICBOX01UVSxWTEFOX0hXVEFHRmF0YUdJTkcsVkxBTl9IV0NTVU1s IGtlLFdPTF9NQUdJQyxMSU5LU3JuZWxUQVRFPgplIGRhCWV0aGVyIDY0IG1vZDo3MDowMjoxMDpm NzoyMAogICAgdGEgYWJvcnQ6ICdUcmFuc2xhdGlvbiBGYXVsdCAoTDEpJyBvbiB3cml0ZQp0cmFw ZnJhbWU6IDB4ZWZlODBiMjgKRlNSPTAwMDAwODA1LCBGQVI9ODAwMDAwNjAsIHNwc3I9NjAwMDAw MTMKcjAgPWMwZTc5NzQwLCByMSA9ODAwMDAwMDAsIHIyID0wMDAwMDAwMSwgcjMgPTAwMDEwMDAw CnI0ID1jNTdmMTAwMCwgcjUgPTAwMDAwMDAxLCByNiA9MDAwMDAwMDAsIHI3ID0wMDAwMDAwMQpy OCA9YzBlNDdmMGMsIHI5ID1jNWJlNTc4MCwgcjEwPWM1N2VmYjAwLCByMTE9ZWZlODBiYzgKcjEy PTAwMDAwMDAwLCBzc3A9ZWZlODBiYjgsIHNscj1jMDk2ZjUyMCwgcGMgPWMwOTZmNTM4CgpbIHRo cmVhZCBwaWQgMjQxIHRpZCAxMDAwNjggXQpTdG9wcGVkIGF0ICAgICAgcmVfZ21paV9yZWFkcmVn KzB4NzQ6ICAgc3RyICAgICByMywgW3IxLCAjMHgwNjBdCmRiPiBidApUcmFjaW5nIHBpZCAyNDEg dGlkIDEwMDA2OCB0ZCAweGM1YmUxMDAwCmRiX3RyYWNlX3NlbGYoKSBhdCBkYl90cmFjZV9zZWxm CiAgICAgICAgIHBjID0gMHhjMGQxNjYxNCAgbHIgPSAweGMwOTQzNmU0IChkYl9oZXgyZGVjKzB4 MWY0KQogICAgICAgICBzcCA9IDB4ZWZlODA4MzggIGZwID0gMHhlZmU4MDg1MApkYl9oZXgyZGVj KCkgYXQgZGJfaGV4MmRlYysweDFmNAogICAgICAgICBwYyA9IDB4YzA5NDM2ZTQgIGxyID0gMHhj MDk0MzMzOCAoZGJfY29tbWFuZF9sb29wKzB4MmY0KQogICAgICAgICBzcCA9IDB4ZWZlODA4NTgg IGZwID0gMHhlZmU4MDhmOAogICAgICAgICByNCA9IDB4MDAwMDAwMDAgIHI1ID0gMHgwMDAwMDAw MAogICAgICAgICByNiA9IDB4YzBkOGMyNzQgcjEwID0gMHhjMGVhYWM1YwpkYl9jb21tYW5kX2xv b3AoKSBhdCBkYl9jb21tYW5kX2xvb3ArMHgyZjQKICAgICAgICAgcGMgPSAweGMwOTQzMzM4ICBs ciA9IDB4YzA5NDMwYjggKGRiX2NvbW1hbmRfbG9vcCsweDc0KQogICAgICAgICBzcCA9IDB4ZWZl ODA5MDAgIGZwID0gMHhlZmU4MDkxMAogICAgICAgICByNCA9IDB4YzBkNmEzNzcgIHI1ID0gMHhj MGQ4NDlhMAogICAgICAgICByNiA9IDB4YzBlYWFjNDggIHI3ID0gMHhlZmU4MGIyOAogICAgICAg ICByOCA9IDB4YzBlOWZhMDAgIHI5ID0gMHhjMGU0MzM2MAogICAgICAgIHIxMCA9IDB4YzBlOWZh MDQKZGJfY29tbWFuZF9sb29wKCkgYXQgZGJfY29tbWFuZF9sb29wKzB4NzQKICAgICAgICAgcGMg PSAweGMwOTQzMGI4ICBsciA9IDB4YzA5NDVkZGMgKGRiX2ZldGNoX2tzeW10YWIrMHgyZDApCiAg ICAgICAgIHNwID0gMHhlZmU4MDkxOCAgZnAgPSAweGVmZTgwYTMwCiAgICAgICAgIHI0ID0gMHgw MDAwMDAwMCAgcjUgPSAweGMwZWFhYzU0CiAgICAgICAgIHI2ID0gMHhjMGU5ZmEyMCByMTAgPSAw eGMwZTlmYTA0CmRiX2ZldGNoX2tzeW10YWIoKSBhdCBkYl9mZXRjaF9rc3ltdGFiKzB4MmQwCiAg ICAgICAgIHBjID0gMHhjMDk0NWRkYyAgbHIgPSAweGMwYWJlNDU0IChrZGJfdHJhcCsweDE4MCkK ICAgICAgICAgc3AgPSAweGVmZTgwYTM4ICBmcCA9IDB4ZWZlODBhNjAKICAgICAgICAgcjQgPSAw eDAwMDAwMDAwICByNSA9IDB4MDAwMDA4MDUKICAgICAgICAgcjYgPSAweGMwZTlmYTIwICByNyA9 IDB4ZWZlODBiMjgKa2RiX3RyYXAoKSBhdCBrZGJfdHJhcCsweDE4MAogICAgICAgICBwYyA9IDB4 YzBhYmU0NTQgIGxyID0gMHhjMGQzMTk4OCAoYWJvcnRfaGFuZGxlcisweDcxNCkKICAgICAgICAg c3AgPSAweGVmZTgwYTY4ICBmcCA9IDB4ZWZlODBhODgKICAgICAgICAgcjQgPSAweGVmZTgwYjI4 ICByNSA9IDB4MDAwMDAwMTMKICAgICAgICAgcjYgPSAweDgwMDAwMDYwICByNyA9IDB4MDAwMDAw MDUKICAgICAgICAgcjggPSAweDAwMDAwODA1ICByOSA9IDB4YzViZTEwMDAKICAgICAgICByMTAg PSAweGVmZTgwYjI4CmFib3J0X2hhbmRsZXIoKSBhdCBhYm9ydF9oYW5kbGVyKzB4NzE0CiAgICAg ICAgIHBjID0gMHhjMGQzMTk4OCAgbHIgPSAweGMwZDMxMmY0IChhYm9ydF9oYW5kbGVyKzB4ODAp CiAgICAgICAgIHNwID0gMHhlZmU4MGE5MCAgZnAgPSAweGVmZTgwYjIwCiAgICAgICAgIHI0ID0g MHgwMDAwMDAyMyAgcjUgPSAweDAwMDAwMDA1CiAgICAgICAgIHI2ID0gMHgwMDAwMDAwMCAgcjcg PSAweDAwMDAwODA1CiAgICAgICAgIHI4ID0gMHgwMDAwMDAxMyByMTAgPSAweGVmZTgwYjI4CmFi b3J0X2hhbmRsZXIoKSBhdCBhYm9ydF9oYW5kbGVyKzB4ODAKICAgICAgICAgcGMgPSAweGMwZDMx MmY0ICBsciA9IDB4YzBkMTdjYmMgKGV4Y2VwdGlvbl9leGl0KQogICAgICAgICBzcCA9IDB4ZWZl ODBiMjggIGZwID0gMHhlZmU4MGJjOAogICAgICAgICByNCA9IDB4YzU3ZjEwMDAgIHI1ID0gMHgw MDAwMDAwMQogICAgICAgICByNiA9IDB4MDAwMDAwMDAgIHI3ID0gMHgwMDAwMDAwMQogICAgICAg ICByOCA9IDB4YzBlNDdmMGMgIHI5ID0gMHhjNWJlNTc4MAogICAgICAgIHIxMCA9IDB4YzU3ZWZi MDAKZXhjZXB0aW9uX2V4aXQoKSBhdCBleGNlcHRpb25fZXhpdAogICAgICAgICBwYyA9IDB4YzBk MTdjYmMgIGxyID0gMHhjMDk2ZjUyMCAocmVfZ21paV9yZWFkcmVnKzB4NWMpCiAgICAgICAgIHNw ID0gMHhlZmU4MGJiOCAgZnAgPSAweGVmZTgwYmM4CiAgICAgICAgIHIwID0gMHhjMGU3OTc0MCAg cjEgPSAweDgwMDAwMDAwCiAgICAgICAgIHIyID0gMHgwMDAwMDAwMSAgcjMgPSAweDAwMDEwMDAw CiAgICAgICAgIHI0ID0gMHhjNTdmMTAwMCAgcjUgPSAweDAwMDAwMDAxCiAgICAgICAgIHI2ID0g MHgwMDAwMDAwMCAgcjcgPSAweDAwMDAwMDAxCiAgICAgICAgIHI4ID0gMHhjMGU0N2YwYyAgcjkg PSAweGM1YmU1NzgwCiAgICAgICAgcjEwID0gMHhjNTdlZmIwMCByMTIgPSAweDAwMDAwMDAwCnJl X2dtaWlfcmVhZHJlZygpIGF0IHJlX2dtaWlfcmVhZHJlZysweDc0CiAgICAgICAgIHBjID0gMHhj MDk2ZjUzOCAgbHIgPSAweGMwOTcyMGI4IChyZV9nbWlpX3dyaXRlcmVnKzB4MmFmMCkKICAgICAg ICAgc3AgPSAweGVmZTgwYmQwICBmcCA9IDB4ZWZlODBiZTAKICAgICAgICAgcjQgPSAweGM1NmM2 ZTgwICByNSA9IDB4YzU3ZjEwMDAKICAgICAgICAgcjYgPSAweDAwMDAwMDAxIHIxMCA9IDB4YzU3 ZWZiMDAKcmVfZ21paV93cml0ZXJlZygpIGF0IHJlX2dtaWlfd3JpdGVyZWcrMHgyYWYwCiAgICAg ICAgIHBjID0gMHhjMDk3MjBiOCAgbHIgPSAweGMwOTU1OGNjICh1a3BoeV9zdGF0dXMrMHg3YykK ICAgICAgICAgc3AgPSAweGVmZTgwYmU4ICBmcCA9IDB4ZWZlODBjMDgKICAgICAgICAgcjQgPSAw eGM1ODRhMjAwICByNSA9IDB4YzU4NGEzMDAKICAgICAgICAgcjYgPSAweDAwMDAwMDAxICByNyA9 IDB4YzBkNmU1NGQKdWtwaHlfc3RhdHVzKCkgYXQgdWtwaHlfc3RhdHVzKzB4N2MKICAgICAgICAg cGMgPSAweGMwOTU1OGNjICBsciA9IDB4YzA5NTU4M2MgKG1paV9waHlfZmxvd3N0YXR1cysweDFl OCkKICAgICAgICAgc3AgPSAweGVmZTgwYzEwICBmcCA9IDB4ZWZlODBjMTgKICAgICAgICAgcjQg PSAweDAwMDAwMDAzICByNSA9IDB4YzU4NGEyMDAKICAgICAgICAgcjYgPSAweGM1N2ZlNDIwICBy NyA9IDB4YzBkNmU1NGQKICAgICAgICAgcjggPSAweGM1N2VmYjAwICByOSA9IDB4YzViZTU3ODAK ICAgICAgICByMTAgPSAweDAwMDAwMDAwCm1paV9waHlfZmxvd3N0YXR1cygpIGF0IG1paV9waHlf Zmxvd3N0YXR1cysweDFlOAogICAgICAgICBwYyA9IDB4YzA5NTU4M2MgIGxyID0gMHhjMDk1Mzlh MCAobWlpX3BvbGxzdGF0KzB4NWMpCiAgICAgICAgIHNwID0gMHhlZmU4MGMyMCAgZnAgPSAweGVm ZTgwYzMwCiAgICAgICAgIHI0ID0gMHhjNTdlZmIwMCAgcjUgPSAweGM1ODRhMjAwCm1paV9wb2xs c3RhdCgpIGF0IG1paV9wb2xsc3RhdCsweDVjCiAgICAgICAgIHBjID0gMHhjMDk1MzlhMCAgbHIg PSAweGMwOTczMDQ0IChyZV9nbWlpX3dyaXRlcmVnKzB4M2E3YykKICAgICAgICAgc3AgPSAweGVm ZTgwYzM4ICBmcCA9IDB4ZWZlODBjNDgKICAgICAgICAgcjQgPSAweGVmZTgwZDQwICByNSA9IDB4 YzU3ZWZiMDAKICAgICAgICAgcjYgPSAweGM1N2YzMTQ0IHIxMCA9IDB4MDAwMDAwMDAKcmVfZ21p aV93cml0ZXJlZygpIGF0IHJlX2dtaWlfd3JpdGVyZWcrMHgzYTdjCiAgICAgICAgIHBjID0gMHhj MDk3MzA0NCAgbHIgPSAweGMwYjVhNzA4IChpZm1lZGlhX2lvY3RsKzB4MTg4KQogICAgICAgICBz cCA9IDB4ZWZlODBjNTAgIGZwID0gMHhlZmU4MGM2OAogICAgICAgICByNCA9IDB4MDAwMDAwMmQg IHI1ID0gMHhlZmU4MGQ0MAogICAgICAgICByNiA9IDB4YzAyODY5MzggIHI3ID0gMHhjNWJlMTAw MAppZm1lZGlhX2lvY3RsKCkgYXQgaWZtZWRpYV9pb2N0bCsweDE4OAogICAgICAgICBwYyA9IDB4 YzBiNWE3MDggIGxyID0gMHhjMGI1MjczNCAoaWZpb2N0bCsweGE4OCkKICAgICAgICAgc3AgPSAw eGVmZTgwYzcwICBmcCA9IDB4ZWZlODBjZTgKICAgICAgICAgcjQgPSAweDAwMDAwMDJkICByNSA9 IDB4YzAyODY5MzgKICAgICAgICAgcjYgPSAweGMwMjg2OTM4ICByNyA9IDB4YzViZTEwMDAKICAg ICAgICAgcjggPSAweGM1ODM5MDAwIHIxMCA9IDB4MDAwMDAwMDAKaWZpb2N0bCgpIGF0IGlmaW9j dGwrMHhhODgKICAgICAgICAgcGMgPSAweGMwYjUyNzM0ICBsciA9IDB4YzBhZDkwYjAgKGtlcm5f aW9jdGwrMHgyMDApCiAgICAgICAgIHNwID0gMHhlZmU4MGNmMCAgZnAgPSAweGVmZTgwZDMwCiAg ICAgICAgIHI0ID0gMHhjNWJlMTAwMCAgcjUgPSAweGMwMjg2OTM4CiAgICAgICAgIHI2ID0gMHgw MDAwMDAwMyAgcjcgPSAweGMwYWUwNjM4CiAgICAgICAgIHI4ID0gMHhlZmU4MGQ0MCAgcjkgPSAw eGM1YjJiMDAwCiAgICAgICAgcjEwID0gMHgwMDAwMDAwMAprZXJuX2lvY3RsKCkgYXQga2Vybl9p b2N0bCsweDIwMAogICAgICAgICBwYyA9IDB4YzBhZDkwYjAgIGxyID0gMHhjMGFkOGU1YyAoc3lz X2lvY3RsKzB4ZmMpCiAgICAgICAgIHNwID0gMHhlZmU4MGQzOCAgZnAgPSAweGVmZTgwZGUwCiAg ICAgICAgIHI0ID0gMHgwMDAwMDAyOCAgcjUgPSAweGVmZTgwZTAwCiAgICAgICAgIHI2ID0gMHhj MDI4NjkzOCAgcjcgPSAweDAwMDAwMDAwCiAgICAgICAgIHI4ID0gMHhlZmU4MGQ0MCAgcjkgPSAw eGM1YmUxMDAwCiAgICAgICAgcjEwID0gMHg0MDAwMDAwMApzeXNfaW9jdGwoKSBhdCBzeXNfaW9j dGwrMHhmYwogICAgICAgICBwYyA9IDB4YzBhZDhlNWMgIGxyID0gMHhjMGQzMGViOCAoc3dpX2hh bmRsZXIrMHgzMWMpCiAgICAgICAgIHNwID0gMHhlZmU4MGRlOCAgZnAgPSAweGVmZTgwZTQ4CiAg ICAgICAgIHI0ID0gMHhjNWJlMTAwMCAgcjUgPSAweGM1YzMyYTk4CiAgICAgICAgIHI2ID0gMHgw MDAwMDAwMCAgcjcgPSAweGMwZWFjNjIwCiAgICAgICAgIHI4ID0gMHgwMDAwMDAwMCAgcjkgPSAw eGVmZTgwZGY4CiAgICAgICAgcjEwID0gMHhiZmJmZWUxOApzd2lfaGFuZGxlcigpIGF0IHN3aV9o YW5kbGVyKzB4MzFjCiAgICAgICAgIHBjID0gMHhjMGQzMGViOCAgbHIgPSAweGMwZDE3YzRjIChz d2lfZXhpdCkKICAgICAgICAgc3AgPSAweGVmZTgwZTUwICBmcCA9IDB4YmZiZmU2NzAKICAgICAg ICAgcjQgPSAweDAwMDM1ZjIwICByNSA9IDB4YmZiZmRlYjgKICAgICAgICAgcjYgPSAweGJmYmZk ZWJhICByNyA9IDB4MDAwMDAwMzYKICAgICAgICAgcjggPSAweDAwMDAwMDAwICByOSA9IDB4MDAw MzdjZGMKICAgICAgICByMTAgPSAweGJmYmZlZTE4CnN3aV9leGl0KCkgYXQgc3dpX2V4aXQKICAg ICAgICAgcGMgPSAweGMwZDE3YzRjICBsciA9IDB4YzBkMTdjNGMgKHN3aV9leGl0KQogICAgICAg ICBzcCA9IDB4ZWZlODBlNTAgIGZwID0gMHhiZmJmZTY3MApkYj4gCgo= --94eb2c0773ec60b22605277e31ba-- From owner-freebsd-arm@freebsd.org Tue Dec 22 16:53: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 77CE1A4E36D for ; Tue, 22 Dec 2015 16:53:15 +0000 (UTC) (envelope-from mmel@freebsd.org) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) by mx1.freebsd.org (Postfix) with ESMTP id 000251A8F; Tue, 22 Dec 2015 16:53:14 +0000 (UTC) (envelope-from mmel@freebsd.org) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id AEB273AC89; Tue, 22 Dec 2015 17:46:23 +0100 (CET) Subject: Re: Translation Fault (L1) while using pmap-v6-new To: Bartosz Szczepanek , freebsd-arm@freebsd.org, skra@freebsd.org References: Cc: Marcin Wojtas From: Michal Meloun Organization: freebsd.org Message-ID: <56797E5F.2030603@freebsd.org> Date: Tue, 22 Dec 2015 17:46:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Tue, 22 Dec 2015 17:46:23 +0100 (CET) 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, 22 Dec 2015 16:53:15 -0000 Dne 22.12.2015 v 16:23 Bartosz Szczepanek napsal(a): > Hello, > > currently I'm working on support for Armada38x on FreeBSD-CURRENT > (patchset was submitted to Phabricator - > https://reviews.freebsd.org/D4210). After switching to ARM_NEW_PMAP > problems related with PCIe subsystem emerged, even though that worked > fine on FreeBSD-10.2. > > My setup consists of Marvell Armada38x GP development board equipped > with Cortex-A9, PCIe controller serviced by arm/mv/mv_pci.c driver and > RealTek GE PCI card (re driver). Enabling ARM_NEW_PMAP leads to > 'Translation Fault (L1)' on write: > >> Starting Network: lo0 re0. >> lo0: flags=8049 metric 0 mtu 16384 >> options=600003 >> inet6 ::1 prefixlen 128 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >> inet 127.0.0.1 netmask 0xff000000 >> nd6 options=21 >> re0: flags=8802 metrnelric 0 mtu 1500 >> mod options=8209b aN_MTU,VLAN_HWTAGbortGING,VLAN_HWCSUM: 'T,WOL_MAGIC,LINKSransTATE> >> on F ether 64lati:70:02:10:f7:20 >> ault (L1)' on write >> trapframe: 0xefe78b40 >> FSR=00000805, FAR=80000060, spsr=60000013 >> r0 =c0e796c0, r1 =80000000, r2 =00000004, r3 =00010000 >> r4 =c57f1000, r5 =c57f1000, r6 =00000000, r7 =00000001 >> r8 =c0e47e8c, r9 =c5be3780, r10=c57efb00, r11=efe78be0 >> r12=efe78d43, ssp=efe78bd0, slr=c0971ef4, pc =c0971f64 >> [ thread pid 241 tid 100068 ] >> Stopped at re_gmii_readreg+0x50: str r3, [r1, #0x060] >> db> > > (re_gmii_readreg is function in re driver, I made it non-static so it > is visible in debugger) > Address it crashes on lies in the PCI devices' memory range, and it > was accessed successfully several times during boot proccess before > crash (I put printfs in the exact function where fault occurs). So it > seems just like the memory mapping has disappeared at some point. I > put kdb_enter in re attach function (long before translation fault), > from that point I see that 0x80000000 mapping exists: > >> pcib0: mem 0xf1080000-0xf1081fff irq 1 on ofwbus0 >> [ thread pid 0 tid 100000 ] >> Stopped at kdb_enter+0x58: ldrb r15, [r15, r15, ror r15]! >> db> show pmap >> pmap: 0xC0EAC544 >> PT2MAP: 0xBFC00000 >> pt2tab: 0xC0F04000 >> 0x80000000: Section 0x8001041A, s:1 g:1 >> 0x80100000: Section 0x8011041A, s:1 g:1 >> 0x80200000: Section 0x8021041A, s:1 g:1 >> 0x80300000: Section 0x8031041A, s:1 g:1 >> ... > > Doing 'show pmap' after crash gives me long, long log without > 0x80000000 occuring. On the other hand, adding vtophys(0x80000060) > line before affected write operation translates address correctly. It > is visible in log attached. > > I've also tried to track various functions removing mapping in > pmap-v6-new, but with no luck. However, problem seems to lie there, as > system boots fine without ARM_NEW_PMAP option. I would be grateful for > you advice - what else can I do to investigate the issue? > > Best regards, > Bartosz Szczepanek > > > > _______________________________________________ > 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" > Isn't 0x80000060 little strange address for KVA? Michal From owner-freebsd-arm@freebsd.org Wed Dec 23 10:45:27 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06F27A501E8 for ; Wed, 23 Dec 2015 10:45:27 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD58D1007 for ; Wed, 23 Dec 2015 10:45:26 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by mail-ig0-x22b.google.com with SMTP id mv3so64946290igc.0 for ; Wed, 23 Dec 2015 02:45:26 -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=ld9OD/6hFIqb9fiVtf9c2BkUDStfaDw0CNYUrmyySlY=; b=bzZv1V7D/lDP5xi+eJN7kSnML8F5sxjVRrpupegBN6os8P0epucSaipdIq0JOZ6bO6 jy/3kZ8xDSpgSAiHJk+BaEdkEWHuouXq0V7Bt/gpZlGe0Ai2WY9RlUQFDn1vOQTSMsqK OQxQyATVGFcOp5uA0MUCOlNFW/42ik2WaGF5o1L8gL9DBO+715xnAmb+ahawoh2phgSh H30PFsapQ8PXZp3ARmlpUKd5zKeDUtjsMVz4F6hAPyEcZ/FFy64U/WWBzNCj7aieyO0q OkuCfanYXr8XxNp2hpiF+sqACYZ2nUc311srzgk1M113oZbp3l7CaPB/6/aOCCDZSGLD xYUQ== MIME-Version: 1.0 X-Received: by 10.50.62.20 with SMTP id u20mr30275754igr.26.1450867526189; Wed, 23 Dec 2015 02:45:26 -0800 (PST) Received: by 10.64.130.38 with HTTP; Wed, 23 Dec 2015 02:45:26 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Dec 2015 11:45:26 +0100 Message-ID: Subject: Re: Translation Fault (L1) while using pmap-v6-new From: Svatopluk Kraus To: Bartosz Szczepanek Cc: "freebsd-arm@freebsd.org" , Marcin Wojtas 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, 23 Dec 2015 10:45:27 -0000 On Tue, Dec 22, 2015 at 4:23 PM, Bartosz Szczepanek wrote: > Hello, > > currently I'm working on support for Armada38x on FreeBSD-CURRENT > (patchset was submitted to Phabricator - > https://reviews.freebsd.org/D4210). After switching to ARM_NEW_PMAP > problems related with PCIe subsystem emerged, even though that worked > fine on FreeBSD-10.2. > > My setup consists of Marvell Armada38x GP development board equipped > with Cortex-A9, PCIe controller serviced by arm/mv/mv_pci.c driver and > RealTek GE PCI card (re driver). Enabling ARM_NEW_PMAP leads to > 'Translation Fault (L1)' on write: > >> Starting Network: lo0 re0. >> lo0: flags=8049 metric 0 mtu 16384 >> options=600003 >> inet6 ::1 prefixlen 128 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >> inet 127.0.0.1 netmask 0xff000000 >> nd6 options=21 >> re0: flags=8802 metrnelric 0 mtu 1500 >> mod options=8209b aN_MTU,VLAN_HWTAGbortGING,VLAN_HWCSUM: 'T,WOL_MAGIC,LINKSransTATE> >> on F ether 64lati:70:02:10:f7:20 >> ault (L1)' on write >> trapframe: 0xefe78b40 >> FSR=00000805, FAR=80000060, spsr=60000013 >> r0 =c0e796c0, r1 =80000000, r2 =00000004, r3 =00010000 >> r4 =c57f1000, r5 =c57f1000, r6 =00000000, r7 =00000001 >> r8 =c0e47e8c, r9 =c5be3780, r10=c57efb00, r11=efe78be0 >> r12=efe78d43, ssp=efe78bd0, slr=c0971ef4, pc =c0971f64 >> [ thread pid 241 tid 100068 ] >> Stopped at re_gmii_readreg+0x50: str r3, [r1, #0x060] >> db> > > (re_gmii_readreg is function in re driver, I made it non-static so it > is visible in debugger) > Address it crashes on lies in the PCI devices' memory range, and it > was accessed successfully several times during boot proccess before > crash (I put printfs in the exact function where fault occurs). So it > seems just like the memory mapping has disappeared at some point. I > put kdb_enter in re attach function (long before translation fault), > from that point I see that 0x80000000 mapping exists: > >> pcib0: mem 0xf1080000-0xf1081fff irq 1 on ofwbus0 >> [ thread pid 0 tid 100000 ] >> Stopped at kdb_enter+0x58: ldrb r15, [r15, r15, ror r15]! >> db> show pmap >> pmap: 0xC0EAC544 >> PT2MAP: 0xBFC00000 >> pt2tab: 0xC0F04000 >> 0x80000000: Section 0x8001041A, s:1 g:1 >> 0x80100000: Section 0x8011041A, s:1 g:1 >> 0x80200000: Section 0x8021041A, s:1 g:1 >> 0x80300000: Section 0x8031041A, s:1 g:1 >> ... According to the show pmap output, there is a global mapping (g:1) on many addresses which are not from KVA (as Michal has already written). KVA starts at 0xC0000000 and global mapping outside of KVA space is not allowed. Thus,probably some malicious driver is doing bad mapping. Maybe it's just coincidence, but 0x80000060 looks like physical address of re(4) memory resource? > > Doing 'show pmap' after crash gives me long, long log without > 0x80000000 occuring. On the other hand, adding vtophys(0x80000060) > line before affected write operation translates address correctly. It > is visible in log attached. > > I've also tried to track various functions removing mapping in > pmap-v6-new, but with no luck. However, problem seems to lie there, as > system boots fine without ARM_NEW_PMAP option. I would be grateful for > you advice - what else can I do to investigate the issue? > > Best regards, > Bartosz Szczepanek From owner-freebsd-arm@freebsd.org Wed Dec 23 16:53:40 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3D82A4F081 for ; Wed, 23 Dec 2015 16:53:39 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9139F1E31 for ; Wed, 23 Dec 2015 16:53:39 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: by mail-lb0-x22f.google.com with SMTP id sv6so42546146lbb.0 for ; Wed, 23 Dec 2015 08:53:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZMR3TfwaKlwamLjRVO9JUJ8JQOXYlRm8tMNQR8N2FpU=; b=xT8Vnrgtzg58FpDmfoDTu6gOV3FNx2axxHvQYVV2K2MYok7W0KLLv+0RWjeoAFrUgl cM/U2mNZYYNpZxK1YHJX4mKaUuvqedPDKissbUCnzYpDzQIDAk4etlkI+VBGvpeQa/yx VFO7g7k0I9NkY/3OASj/Mb7E0lTxRSbd2k07hRP+TLN3Y3ckO8xKGrd299ED72LKuhS8 TjoJmSmOQMwZyiFxQqhNI+hsnW0OmX/xEtnxLpIBAaNzh6eVAmhvdrCCc4ayNWxGn48F wY5sb2ICzVQkiZ8DbJSRG2j5f0lOCMl3WoVbnhDKXFWWJhikFH4m85p/JsumnDYh8Kwj bDXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZMR3TfwaKlwamLjRVO9JUJ8JQOXYlRm8tMNQR8N2FpU=; b=SZPysuSK8GoCBDuXOPhoWbRH5fx7tI+RbgpP3ZzFxolRJ9PrXK096NS5fuzBQj/8YB wZeHk4kpVu9XQuw8rUDqq03dU9hDhY/M8ILd7XppFFvnbKiseOA4LZr/ra2DExJGWXHG IyGbT9hSXPajpL+nLnqes6bvGNePWX8Y/bRb8Isd+zzXEgJOPhUuq+/jpXHrHEhsLf3A xeJFsnih/lBLp24wmSrcgsycoE53VOl5RHijvl0F/fvN7dijd+8nhGiyNsG0MVvCEUWb i79fVo93Y0/3hMpEz92AtevOOCoID4EMZseEAfmcGqdpQ9U1CooUUtrQKnuSYdUqGf0D f3og== X-Gm-Message-State: ALoCoQnD1iQ2RHwR5ZXULUq39bhmtb2M0NmkTfwRDXkp5QX3bVqAA2ng+F5U4j7ALMqT764bgqPl9KsWSbre6dMUR7jrD1/lkQ== X-Received: by 10.112.160.202 with SMTP id xm10mr8965463lbb.22.1450889616951; Wed, 23 Dec 2015 08:53:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.139.194 with HTTP; Wed, 23 Dec 2015 08:53:17 -0800 (PST) In-Reply-To: References: From: Zbigniew Bodek Date: Wed, 23 Dec 2015 17:53:17 +0100 Message-ID: Subject: Re: Various panics while using HWPMC on ARM64 To: Ruslan Bukin Cc: Andrew Turner , "freebsd-arm@freebsd.org" , Ed Maste 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, 23 Dec 2015 16:53:40 -0000 Hi, I go into new panics although quite similar to the previously mentioned in both SMP and UP but this time I tried to use DTrace. Can anyone check this on another ARM64 platform? I used ThunderX and FreeBSD-CURRENT r292654. Best regards zbb Please check out below for panic outputs: SMP: -------- root@thunder_crb4:~ # procsystime Tracing... Hit Ctrl-C to end... ^C Elapsed Times for all processes, x0: 1 x1: 0 x2: ffffff800052c911 x3: deadc0d8 x4: 1a2 x5: ffffff854a976860 x6: 0 x7: 100 x8: deadc0de x9: 0 x10: c4d4ae68 x11: 6c4d4ae68 x12: 80000000 x13: 0 x14: b x15: 274f x16: ffffff80481a97f8 x17: ffffff8048196814 x18: ffffff854a9764b0 x19: 989680 x20: ffffff8000708000 x21: ffffff8000702038 x22: ffffffc004219000 x23: ffffff8000702050 x24: 3938700 x25: 3938700 x26: ffffff80006e2000 x27: ffffffc0041129a0 x28: 39386ff x29: ffffff854a976530 x30: ffffff854a976530 sp: ffffff854a9764b0 lr: ffffff8000244760 elr: ffffff80002448e8 spsr: 600003c5 far: deadc174 esr: 96000007 panic: data abort in critical section or under mutex cpuid = 0 KDB: enter: panic [ thread pid 11 tid 100004 ] Stopped at kdb_enter+0x40: db> UP: -------- root@thunder_crb4:~ # kldload dtraceall IMPLEMENT ME: dtrace_toxic_ranges x0: ffffff8000299740 x1: ffffffc0040cd100 x2: ffffff8000299740 x3: ffffff8043655a70 x4: ffffff8000299740 x5: 0 x6: ffffff87cba9c0a8 x7: 0 x8: ffffffc0129484d0 x9: 1 x10: 1 x11: 0 x12: ffffffc003e7ed88 x13: ffffffc007ab0280 x14: 400000 x15: ffffff800068c000 x16: ffffff80436687b8 x17: ffffff8000299690 x18: ffffff87cba9c010 x19: ffffff8043655a70 x20: ffffff8000299740 x21: ffffff8000299740 x22: ffffffc0040cd100 x23: ffffffc003e7ed40 x24: 8 x25: 1 x26: ffffff8043669000 x27: ffffff8043669000 x28: ffffff8043669000 x29: ffffff87cba9c030 x30: ffffff87cba9c030 sp: ffffff87cba9c010 lr: ffffff80002996c0 elr: ffffffc0040cd100 spsr: 800003c5 panic: Unknown kernel exception 0 esr_el1 2000000 KDB: enter: panic [ thread pid 719 tid 100062 ] Stopped at kdb_enter+0x40: db> 2015-12-14 16:24 GMT+01:00 Zbigniew Bodek : > Hello, > > Did you have time to look into that? Do you have any clues what could > be wrong here? > We would like to use hwpmc for profiling so your help will be very > much appreciated. > > Best regards > zbb > > 2015-12-09 13:06 GMT+01:00 Zbigniew Bodek : >> Hello Ed, >> >> Done. I also check what happens when SMP is disabled and the kassert >> is triggered: >> >> root@thunderx_crb4:~ # pmcstat -S CPU_CYCLES -O cpu_cycles.pmc >> ^Cpanic: [pmc,4256] cpu 0 didn't find a sample to collect >> KDB: stack backtrace: >> db_trace_self() at db_trace_self_wrapper+0x28 >> pc = 0xffffff80004e9aac lr = 0xffffff800006d8b4 >> sp = 0xffffff87cba976e0 fp = 0xffffff87cba97800 >> >> db_trace_self_wrapper() at vpanic+0x9c >> pc = 0xffffff800006d8b4 lr = 0xffffff800027136c >> sp = 0xffffff87cba97810 fp = 0xffffff87cba97880 >> >> vpanic() at kassert_panic+0x160 >> pc = 0xffffff800027136c lr = 0xffffff80002712cc >> sp = 0xffffff87cba97890 fp = 0xffffff87cba97950 >> >> kassert_panic() at pmc_capture_user_callchain+0x1a4 >> pc = 0xffffff80002712cc lr = 0xffffff80000e1444 >> sp = 0xffffff87cba97960 fp = 0xffffff87cba979c0 >> >> pmc_capture_user_callchain() at pmc_hook_handler+0x7c0 >> pc = 0xffffff80000e1444 lr = 0xffffff80000dfb78 >> sp = 0xffffff87cba979d0 fp = 0xffffff87cba97a50 >> >> pmc_hook_handler() at ast+0x14c >> pc = 0xffffff80000dfb78 lr = 0xffffff80002b976c >> sp = 0xffffff87cba97a60 fp = 0xffffff87cba97a90 >> >> ast() at handle_el0_sync+0x90 >> pc = 0xffffff80002b976c lr = 0xffffff80004eb224 >> sp = 0xffffff87cba97aa0 fp = 0xffffff87cba97bb0 >> >> handle_el0_sync() at 0x406d60 >> pc = 0xffffff80004eb224 lr = 0x0000000000406d60 >> sp = 0xffffff87cba97bc0 fp = 0x0000007ffffff540 >> >> KDB: enter: panic >> [ thread pid 679 tid 100061 ] >> Stopped at kdb_enter+0x40: >> db> >> >> >> when invariants options is disabled I only get: >> >> root@thunderx_crb4:~ # pmcstat -S CPU_CYCLES -O cpu_cycles.pmc >> ^Cpmcstat: WARNING: sampling was paused at least 1 time. >> Please consider tuning the "kern.hwpmc.nsamples" tunable. >> >> >> Best regards >> zbb >> >> 2015-12-08 20:59 GMT+01:00 Ed Maste : >>> On 8 December 2015 at 14:34, Zbigniew Bodek wrote: >>>> Hello, >>>> >>>> I encountered some problems with FreeBSD on ARM64 while using hwpmc. >>>> Some of the errors that I found are listed below: >>>> >>>> * panic: Unknown kernel exception 0 esr_el1 2000000 >>>> * panic: data abort in critical section or under mutex >>>> * panic: VFP exception in the kernel >>>> * panic: Unknown kernel exception 21 esr_el1 86000006 >>> >>> Can you add these notes to PR 204686? I think there are SMP issues in >>> arm64 hwpmc that need to be resolved. From owner-freebsd-arm@freebsd.org Wed Dec 23 22:02:07 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 6735DA50B3C for ; Wed, 23 Dec 2015 22:02:07 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC3191B28 for ; Wed, 23 Dec 2015 22:02:06 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1aBrTk-0001r5-1y for freebsd-arm@freebsd.org; Wed, 23 Dec 2015 23:01:57 +0100 Content-Type: multipart/mixed; boundary=----------7Q8RxOqXNDXZskN6CFMV3p To: freebsd-arm@freebsd.org Date: Wed, 23 Dec 2015 23:01:43 +0100 Subject: ports-mgmt/pkg does not build MIME-Version: 1.0 From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 45b8b234c327cf3ce4cda0428fe56d1c 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, 23 Dec 2015 22:02:07 -0000 ------------7Q8RxOqXNDXZskN6CFMV3p Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello, I upgraded my Sheevaplug from CURRENT r285336 (Jul 10) to r292343 (Dec 16). This went from clang 3.6.1 to 3.7.0. This runs, but building potrs-mgmt/pkg does not work. The error of clang is: error: no handler registered for module format 'raw' fatal error: error in backend: unknown module format See http://www.klop.ws/config.log for more information. What could be the cause of this? Or what information can I provide to help? Regards, Ronald. ------------7Q8RxOqXNDXZskN6CFMV3p Content-Disposition: attachment; filename=config.log Content-Type: application/octet-stream; name=config.log Content-Transfer-Encoding: Base64 VGhpcyBmaWxlIGNvbnRhaW5zIGFueSBtZXNzYWdlcyBwcm9kdWNlZCBieSBjb21w aWxlcnMgd2hpbGUKcnVubmluZyBjb25maWd1cmUsIHRvIGFpZCBkZWJ1Z2dpbmcg aWYgY29uZmlndXJlIG1ha2VzIGEgbWlzdGFrZS4KCkl0IHdhcyBjcmVhdGVkIGJ5 IHBrZyBjb25maWd1cmUgMS42LjIsIHdoaWNoIHdhcwpnZW5lcmF0ZWQgYnkgR05V IEF1dG9jb25mIDIuNjkuICBJbnZvY2F0aW9uIGNvbW1hbmQgbGluZSB3YXMKCiAg JCAuL2NvbmZpZ3VyZSAtLWRpc2FibGUtbWFpbnRhaW5lci1tb2RlIC0tcHJlZml4 PS91c3IvbG9jYWwgLS1sb2NhbHN0YXRlZGlyPS92YXIgLS1tYW5kaXI9L3Vzci9s b2NhbC9tYW4gLS1pbmZvZGlyPS91c3IvbG9jYWwvaW5mby8gLS1idWlsZD1hcm0t cG9ydGJsZC1mcmVlYnNkMTEuMAoKIyMgLS0tLS0tLS0tICMjCiMjIFBsYXRmb3Jt LiAjIwojIyAtLS0tLS0tLS0gIyMKCmhvc3RuYW1lID0gc2hlZXZhMi5rbG9wLndz CnVuYW1lIC1tID0gYXJtCnVuYW1lIC1yID0gMTEuMC1DVVJSRU5UCnVuYW1lIC1z ID0gRnJlZUJTRAp1bmFtZSAtdiA9IEZyZWVCU0QgMTEuMC1DVVJSRU5UICMxMiBy MjkyMzQzTTogV2VkIERlYyAxNiAyMzoyMzo1MyBDRVQgMjAxNSAgICAgcm9vdEBz amFraWUua2xvcC53czovdXNyL29iai1hcm0vYXJtLmFybS91c3Ivc3JjLWFybS9z eXMvU0hFRVZBUExVRyAKCi91c3IvYmluL3VuYW1lIC1wID0gYXJtCi9iaW4vdW5h bWUgLVggICAgID0gdW5rbm93bgoKL2Jpbi9hcmNoICAgICAgICAgICAgICA9IHVu a25vd24KL3Vzci9iaW4vYXJjaCAtayAgICAgICA9IHVua25vd24KL3Vzci9jb252 ZXgvZ2V0c3lzaW5mbyA9IHVua25vd24KL3Vzci9iaW4vaG9zdGluZm8gICAgICA9 IHVua25vd24KL2Jpbi9tYWNoaW5lICAgICAgICAgICA9IHVua25vd24KL3Vzci9i aW4vb3NsZXZlbCAgICAgICA9IHVua25vd24KL2Jpbi91bml2ZXJzZSAgICAgICAg ICA9IHVua25vd24KClBBVEg6IC9zYmluClBBVEg6IC9iaW4KUEFUSDogL3Vzci9z YmluClBBVEg6IC91c3IvYmluClBBVEg6IC91c3IvbG9jYWwvc2JpbgpQQVRIOiAv dXNyL2xvY2FsL2JpbgpQQVRIOiAvcm9vdC9iaW4KCgojIyAtLS0tLS0tLS0tLSAj IwojIyBDb3JlIHRlc3RzLiAjIwojIyAtLS0tLS0tLS0tLSAjIwoKY29uZmlndXJl OjIzMzY6IGxvYWRpbmcgc2l0ZSBzY3JpcHQgL3Vzci9wb3J0cy9UZW1wbGF0ZXMv Y29uZmlnLnNpdGUKfCAjICRGcmVlQlNEOiBoZWFkL1RlbXBsYXRlcy9jb25maWcu c2l0ZSA0MDAzOTIgMjAxNS0xMC0yOCAxNDoyMzo1MVogYmRyZXdlcnkgJAp8ICMg RG8gbm90IGFkZDoKfCAjCS0gdG9vbGNoYWluIHJlbGF0ZWQKfCAjCS0gYXJjaC1k ZXBlbmRlbnQgdmFsdWVzCnwgIwktIGFueXRoaW5nICI9bm8iIHVubGVzcyBndWFy YW50ZWVkIHRvIG5ldmVyIGJlCnwgIwkgIGltcGxlbWVudGVkIGluIEZyZWVCU0QK fCAjCS0gYWxzbyBhdm9pZCAid29ya2luZyIgdmFsdWVzCnwgIyBUaGlzIGZpbGUg bXVzdCByZWZsZWN0IHRoZSBvbGRlc3Qgc3VwcG9ydGVkIFJlbGVhc2UuCnwgIwp8 ICNNQUlOVEFJTkVSPQlwb3J0bWdyQEZyZWVCU0Qub3JnCnwgCnwgIyBQYXRoCnwg OiAke2FjX2N2X3BhdGhfQlpJUDI9L3Vzci9iaW4vYnppcDJ9CnwgOiAke2FjX2N2 X3BhdGhfRUdSRVA9L3Vzci9iaW4vZWdyZXB9CnwgOiAke2FjX2N2X3BhdGhfRkdS RVA9L3Vzci9iaW4vZmdyZXB9CnwgOiAke2FjX2N2X3BhdGhfR1JFUD0vdXNyL2Jp bi9ncmVwfQp8IDogJHthY19jdl9wYXRoX0daSVA9L3Vzci9iaW4vZ3ppcH0KfCA6 ICR7YWNfY3ZfcGF0aF9NS1RFTVBfQ09NTUFORD0vdXNyL2Jpbi9ta3RlbXB9Cnwg OiAke2FjX2N2X3BhdGhfU0VEPS91c3IvYmluL3NlZH0KfCA6ICR7YWNfY3ZfcGF0 aF9pbnN0YWxsPS91c3IvYmluL2luc3RhbGx9CnwgOiAke2FjX2N2X3BhdGhfbWtk aXI9L2Jpbi9ta2Rpcn0KfCA6ICR7YWNfY3ZfcHJvZ19BV0s9L3Vzci9iaW4vYXdr fQp8IDogJHthY19jdl9wcm9nX1NFRD0vdXNyL2Jpbi9zZWR9CnwgOiAke2FtX2N2 X3Byb2dfdGFyX3VzdGFyPS91c3IvYmluL3Rhcn0KfCA6ICR7Y2xfY3ZfcHJvZ19M Tj0vYmluL2xufQp8IDogJHtjbF9jdl9wcm9nX2NwPScvYmluL2NwIC1wJ30KfCA6 ICR7bHRfY3ZfcGF0aF9NQUdJQ19DTUQ9L3Vzci9iaW4vZmlsZX0KfCAKfCAjIEhl YWRlcnMKfCA6ICR7YWNfY3ZfaGVhZGVyX2FsbG9jYV9oPW5vfQp8IDogJHthY19j dl9oZWFkZXJfYXJwYV9pbmV0X2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfYXJw YV9uYW1lc2VyX2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfY3R5cGVfaD15ZXN9 CnwgOiAke2FjX2N2X2hlYWRlcl9kaXJlbnRfaD15ZXN9CnwgOiAke2FjX2N2X2hl YWRlcl9kbGZjbl9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX2VsZl9oPXllc30K fCA6ICR7YWNfY3ZfaGVhZGVyX2Vycm5vX2g9eWVzfQp8IDogJHthY19jdl9oZWFk ZXJfZmNudGxfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9mbG9hdF9oPXllc30K fCA6ICR7YWNfY3ZfaGVhZGVyX2Zsb2F0aW5ncG9pbnRfaD15ZXN9CnwgOiAke2Fj X2N2X2hlYWRlcl9nZXRvcHRfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9nbG9i X2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfaW50dHlwZXNfaD15ZXN9CnwgOiAk e2FjX2N2X2hlYWRlcl9sYW5naW5mb19oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVy X2xpYmdlbl9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX2xpYnV0aWxfaD15ZXN9 CnwgOiAke2FjX2N2X2hlYWRlcl9saW1pdHNfaD15ZXN9CnwgOiAke2FjX2N2X2hl YWRlcl9sb2dpbl9jYXBfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9tYXRoX2g9 eWVzfQp8IDogJHthY19jdl9oZWFkZXJfbWVtb3J5X2g9eWVzfQp8IDogJHthY19j dl9oZWFkZXJfbWluaXhfY29uZmlnX2g9bm99CnwgOiAke2FjX2N2X2hlYWRlcl9u ZXRfaWZfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9uZXRfaWZfbWVkaWFfaD15 ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9uZXRfaWZfdGFwX2g9eWVzfQp8IDogJHth Y19jdl9oZWFkZXJfbmV0X2lmX3R1bl9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVy X25ldGRiX2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfbmV0aW5ldF9pbl9oPXll c30KfCA6ICR7YWNfY3ZfaGVhZGVyX3BhdGhzX2g9eWVzfQp8IDogJHthY19jdl9o ZWFkZXJfcG9sbF9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX3B3ZF9oPXllc30K fCA6ICR7YWNfY3ZfaGVhZGVyX3JlYWRwYXNzcGhyYXNlX2g9eWVzfQp8IDogJHth Y19jdl9oZWFkZXJfcmVzb2x2X2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfcnBj X3R5cGVzX2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfc2NoZWRfaD15ZXN9Cnwg OiAke2FjX2N2X2hlYWRlcl9zZWFyY2hfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRl cl9zZWN1cml0eV9wYW1fYXBwbF9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX3Np Z25hbF9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX3NwYXduX2g9eWVzfQp8IDog JHthY19jdl9oZWFkZXJfc3RkYXJnX2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJf c3RkYm9vbF9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX3N0ZGM9eWVzfQp8IDog JHthY19jdl9oZWFkZXJfc3RkZGVmX2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJf c3RkaW50X2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfc3RkaW9faD15ZXN9Cnwg OiAke2FjX2N2X2hlYWRlcl9zdGRsaWJfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRl cl9zdHJpbmdfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9zdHJpbmdzX2g9eWVz fQp8IDogJHthY19jdl9oZWFkZXJfc3lzX2FjbF9oPXllc30KfCA6ICR7YWNfY3Zf aGVhZGVyX3N5c19jZGVmc19oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX3N5c19k aXJfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9zeXNfZmNudGxfaD15ZXN9Cnwg OiAke2FjX2N2X2hlYWRlcl9zeXNfZmlsZV9oPXllc30KfCA6ICR7YWNfY3ZfaGVh ZGVyX3N5c19pb2N0bF9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX3N5c19tbWFu X2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfc3lzX21vdW50X2g9eWVzfQp8IDog JHthY19jdl9oZWFkZXJfc3lzX21zZ19oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVy X3N5c19wYXJhbV9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX3N5c19wb2xsX2g9 eWVzfQp8IDogJHthY19jdl9oZWFkZXJfc3lzX3B0cmFjZV9oPXllc30KfCA6ICR7 YWNfY3ZfaGVhZGVyX3N5c19zZWxlY3RfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRl cl9zeXNfc29ja2V0X2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfc3lzX3N0YXRf aD15ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl9zeXNfc3RhdHZmc19oPXllc30KfCA6 ICR7YWNfY3ZfaGVhZGVyX3N5c190aW1lX2g9eWVzfQp8IDogJHthY19jdl9oZWFk ZXJfc3lzX3RpbWVyc19oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX3N5c190aW1l c19oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVyX3N5c190eXBlc19oPXllc30KfCA6 ICR7YWNfY3ZfaGVhZGVyX3N5c191bl9oPXllc30KfCA6ICR7YWNfY3ZfaGVhZGVy X3N5c193YWl0X2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfdGltZV9oPXllc30K fCA6ICR7YWNfY3ZfaGVhZGVyX3R0eWVudF9oPXllc30KfCA6ICR7YWNfY3ZfaGVh ZGVyX3Vjb250ZXh0X2g9eWVzfQp8IDogJHthY19jdl9oZWFkZXJfdW5pc3RkX2g9 eWVzfQp8IDogJHthY19jdl9oZWFkZXJfdXRpbWVfaD15ZXN9CnwgOiAke2FjX2N2 X2hlYWRlcl92aXNfaD15ZXN9CnwgOiAke2FjX2N2X2hlYWRlcl93Y2hhcl9oPXll c30KfCA6ICR7YWNfY3ZfaGVhZGVyX3djdHlwZV9oPXllc30KfCA6ICR7YWNfY3Zf aGVhZGVyX3psaWJfaD15ZXN9CnwgCnwgOiAke2dsX2N2X2hlYWRlcl93Y2hhcl9o X2NvcnJlY3RfaW5saW5lPXllc30KfCAKfCA6ICR7YWNfY3ZfaGVhZGVyX2FyZ3pf aD1ub30KfCA6ICR7YWNfY3ZfaGVhZGVyX2J5dGVzd2FwX2g9bm99CnwgOiAke2Fj X2N2X2hlYWRlcl9kbF9oPW5vfQp8IDogJHthY19jdl9oZWFkZXJfbWFsbG9jX2g9 bm99CnwgOiAke2FjX2N2X2hlYWRlcl9yYW5kb21faD1ub30KfCA6ICR7YWNfY3Zf aGVhZGVyX3Zmb3JrX2g9bm99CnwgCnwgIyBUaGlzIGFwcGVhcnMgaW4gRnJlZUJT RCAxMCBkbyBub3QgY2FjaGUgaXQuCnwgIzogJHtnbF9jdl9oYXZlX3Jhd19kZWNs X3N0cmNocm51bD15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfbWVtY3B5 PW5vfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX21lbW1lbT15ZXN9CnwgOiAk e2dsX2N2X2hhdmVfcmF3X2RlY2xfbWVtcmNocj15ZXN9CnwgOiAke2dsX2N2X2hh dmVfcmF3X2RlY2xfcmF3bWVtY2hyPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdf ZGVjbF9zdHBjcHk9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3N0cG5j cHk9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3N0cmNhc2VzdHI9eWVz fQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3N0cmR1cD15ZXN9CnwgOiAke2ds X2N2X2hhdmVfcmF3X2RlY2xfc3RybmNhdD15ZXN9CnwgOiAke2dsX2N2X2hhdmVf cmF3X2RlY2xfc3RybmR1cD15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xf c3Rybmxlbj15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfc3RycGJyaz15 ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfc3Ryc2VwPXllc30KfCA6ICR7 Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9zdHJzaWduYWw9eWVzfQp8IDogJHtnbF9jdl9o YXZlX3Jhd19kZWNsX3N0cnRva19yPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdf ZGVjbF9zdHJ2ZXJzY21wPW5vfQp8IAp8ICMgVHlwZQp8IDogJHthY19jdl9jX2lu dDE2X3Q9eWVzfQp8IDogJHthY19jdl9jX2ludDMyX3Q9eWVzfQp8IDogJHthY19j dl9jX2ludDY0X3Q9eWVzfQp8IDogJHthY19jdl9jX2ludDhfdD15ZXN9CnwgOiAk e2FjX2N2X2NfdWludDE2X3Q9eWVzfQp8IDogJHthY19jdl9jX3VpbnQzMl90PXll c30KfCA6ICR7YWNfY3ZfY191aW50NjRfdD15ZXN9CnwgOiAke2FjX2N2X2NfdWlu dDhfdD15ZXN9CnwgCnwgOiAke2FjX2N2X3R5cGVfX0Jvb2w9eWVzfQp8IDogJHth Y19jdl90eXBlX2NoYXI9eWVzfQp8IDogJHthY19jdl90eXBlX2NoYXJfcD15ZXN9 CnwgOiAke2FjX2N2X3R5cGVfZnNibGtjbnRfdD15ZXN9CnwgOiAke2FjX2N2X3R5 cGVfZnNmaWxjbnRfdD15ZXN9CnwgOiAke2FjX2N2X3R5cGVfaW5fYWRkcl90PXll c30KfCA6ICR7YWNfY3ZfdHlwZV9pbl9wb3J0X3Q9eWVzfQp8IDogJHthY19jdl90 eXBlX2ludDE2X3Q9eWVzfQp8IDogJHthY19jdl90eXBlX2ludDMyX3Q9eWVzfQp8 IDogJHthY19jdl90eXBlX2ludD15ZXN9CnwgOiAke2FjX2N2X3R5cGVfaW50bWF4 X3Q9eWVzfQp8IDogJHthY19jdl90eXBlX2xvbmc9eWVzfQp8IDogJHthY19jdl90 eXBlX2xvbmdfZG91YmxlPXllc30KfCA6ICR7YWNfY3ZfdHlwZV9sb25nX2xvbmc9 eWVzfQp8IDogJHthY19jdl90eXBlX2xvbmdfbG9uZ19pbnQ9eWVzfQp8IDogJHth Y19jdl90eXBlX21ic3RhdGVfdD15ZXN9CnwgOiAke2FjX2N2X3R5cGVfbW9kZV90 PXllc30KfCA6ICR7YWNfY3ZfdHlwZV9ubGlua190PXllc30KfCA6ICR7YWNfY3Zf dHlwZV9vZmZfdD15ZXN9CnwgOiAke2FjX2N2X3R5cGVfcGlkX3Q9eWVzfQp8IDog JHthY19jdl90eXBlX3Bvc2l4X3NwYXduX2ZpbGVfYWN0aW9uc190PXllc30KfCA6 ICR7YWNfY3ZfdHlwZV9wb3NpeF9zcGF3bmF0dHJfdD15ZXN9CnwgOiAke2FjX2N2 X3R5cGVfcHRyZGlmZl90PXllc30KfCA6ICR7YWNfY3ZfdHlwZV9zaG9ydD15ZXN9 CnwgOiAke2FjX2N2X3R5cGVfc2lnX2F0b21pY190PXllc30KfCA6ICR7YWNfY3Zf dHlwZV9zaWdzZXRfdD15ZXN9CnwgOiAke2FjX2N2X3R5cGVfc2l6ZV90PXllc30K fCA6ICR7YWNfY3ZfdHlwZV9zb2NrbGVuX3Q9eWVzfQp8IDogJHthY19jdl90eXBl X3NzaXplX3Q9eWVzfQp8IDogJHthY19jdl90eXBlX3N0YWNrX3Q9eWVzfQp8IDog JHthY19jdl90eXBlX3N0cnVjdF90aW1lc3BlYz15ZXN9CnwgOiAke2FjX2N2X3R5 cGVfdV9jaGFyPXllc30KfCA6ICR7YWNfY3ZfdHlwZV91X2ludDE2X3Q9eWVzfQp8 IDogJHthY19jdl90eXBlX3VfaW50MzJfdD15ZXN9CnwgOiAke2FjX2N2X3R5cGVf dV9pbnQ4X3Q9eWVzfQp8IDogJHthY19jdl90eXBlX3VfaW50PXllc30KfCA6ICR7 YWNfY3ZfdHlwZV91X2xvbmc9eWVzfQp8IDogJHthY19jdl90eXBlX3Vfc2hvcnQ9 eWVzfQp8IDogJHthY19jdl90eXBlX3VpZF90PXllc30KfCA6ICR7YWNfY3ZfdHlw ZV91aW50cHRyX3Q9eWVzfQp8IDogJHthY19jdl90eXBlX3Vuc2lnbmVkX2NoYXI9 eWVzfQp8IDogJHthY19jdl90eXBlX3Vuc2lnbmVkX2ludD15ZXN9CnwgOiAke2Fj X2N2X3R5cGVfdW5zaWduZWRfbG9uZz15ZXN9CnwgOiAke2FjX2N2X3R5cGVfdW5z aWduZWRfbG9uZ19sb25nPXllc30KfCA6ICR7YWNfY3ZfdHlwZV91bnNpZ25lZF9s b25nX2xvbmdfaW50PXllc30KfCA6ICR7YWNfY3ZfdHlwZV91bnNpZ25lZF9zaG9y dD15ZXN9CnwgOiAke2FjX2N2X3R5cGVfdm9sYXRpbGVfc2lnX2F0b21pY190PXll c30KfCA6ICR7YWNfY3ZfdHlwZV93Y2hhcl90PXllc30KfCA6ICR7YWNfY3ZfdHlw ZV93aW50X3Q9eWVzfQp8IAp8IDogJHtnbF9jdl9zaWdhbHRzdGFja19sb3dfYmFz ZT15ZXN9CnwgOiAke2dsX2N2X3NpemVfbWF4PXllc30KfCA6ICR7Z2xfY3ZfdHlw ZV9zaWdzZXRfdD15ZXN9CnwgOiAke2dsX2N2X3R5cGVfd2NoYXJfdF9zaWduZWQ9 eWVzfQp8IDogJHtnbF9jdl90eXBlX3djdHJhbnNfdD15ZXN9CnwgOiAke2dsX2N2 X3R5cGVfd2N0eXBlX3Q9eWVzfQp8IDogJHtnbF9jdl90eXBlX3dpbnRfdF9zaWdu ZWQ9eWVzfQp8IDogJHtnbF9jdl92YXJfc3RkaW5fbGFyZ2Vfb2Zmc2V0PXllc30K fCA6ICR7Z3RfY3ZfY19pbnRtYXhfdD15ZXN9CnwgOiAke2d0X2N2X2Nfd2NoYXJf dD15ZXN9CnwgOiAke2d0X2N2X2Nfd2ludF90PXllc30KfCA6ICR7Z3RfY3ZfZnVu Y19wcmludGZfcG9zaXg9eWVzfQp8IDogJHtndF9jdl9pbnRfZGl2Ynl6ZXJvX3Np Z2ZwZT15ZXN9CnwgOiAke2d0X2N2X3NpZ2luZm9fdD15ZXN9CnwgOiAke2d0X2N2 X3NzaXplX3Q9eWVzfQp8IAp8ICMgbGliCnwgOiAke2FjX2N2X2xpYl9jcnlwdF9j cnlwdD15ZXN9CnwgOiAke2FjX2N2X2xpYl9lZGl0X2VsX2luaXQ9eWVzfQp8IDog JHthY19jdl9saWJfcGFtX3BhbV9zZXRfaXRlbT15ZXN9CnwgOiAke2FjX2N2X2xp Yl96X2RlZmxhdGU9eWVzfQp8IDogJHthY19jdl9saWJjX2RlZmluZXNfX19wcm9n bmFtZT15ZXN9CnwgOiAke2FjX2N2X2xpYmNfZGVmaW5lc19zeXNfZXJybGlzdD15 ZXN9CnwgOiAke2FjX2N2X2xpYmNfZGVmaW5lc19zeXNfbmVycj15ZXN9CnwgCnwg IyBTdHJ1Y3QKfCA6ICR7YWNfY3ZfbWVtYmVyX0hFQURFUl9hZD15ZXN9CnwgOiAk e2FjX2N2X21lbWJlcl9zdHJ1Y3RfX19yZXNfc3RhdGVfcmV0cmFucz15ZXN9Cnwg OiAke2FjX2N2X21lbWJlcl9zdHJ1Y3Rfc2lnYWN0aW9uX3NhX3NpZ2FjdGlvbj15 ZXN9CnwgOiAke2FjX2N2X21lbWJlcl9zdHJ1Y3Rfc29ja2FkZHJfaW42X3NpbjZf c2NvcGVfaWQ9eWVzfQp8IDogJHthY19jdl9tZW1iZXJfc3RydWN0X3N0YXRfc3Rf Ymxrc2l6ZT15ZXN9CnwgCnwgOiAke2dsX2N2X3N5c19zdHJ1Y3RfdGltZXNwZWNf aW5fdGltZV9oPXllc30KfCA6ICR7Z2xfY3Zfc3lzX3N0cnVjdF90aW1ldmFsPXll c30KfCAKfCAjIEhhcyBhcHBlYXJyZWQgaW4gRnJlZUJTRCAxMAp8ICM6ICR7YWNf Y3ZfZnVuY193YWl0aWQ9eWVzfQp8ICMgSGFzIGFwcGVhcnJlZCBpbiBGcmVlQlNE IDEwCnwgIzogJHthY19jdl9mdW5jX3N0cmNocm51bD15ZXN9CnwgIyBIYXMgYXBw ZWFycmVkIGluIEZyZWVCU0QgOQp8ICM6ICR7YWNfY3ZfZnVuY191c2Vsb2NhbGU9 eWVzfQp8ICM6ICR7YWNfY3ZfZnVuY19uZXdsb2NhbGU9eWVzfQp8IAp8ICMgRnVu Y3Rpb25zCnwgOiAke2FjX2N2X2Z1bmNfX19iNjRfbnRvcD15ZXN9CnwgOiAke2Fj X2N2X2Z1bmNfX19iNjRfcHRvbj15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfX2dldGxv bmc9eWVzfQp8IDogJHthY19jdl9mdW5jX19nZXRzaG9ydD15ZXN9CnwgOiAke2Fj X2N2X2Z1bmNfX2dldHNob3J0PXllc30KfCA6ICR7YWNfY3ZfZnVuY19fc3RhdD15 ZXN9CnwgOiAke2FjX2N2X2Z1bmNfYWNsX2NyZWF0ZV9lbnRyeV9ucD15ZXN9Cnwg OiAke2FjX2N2X2Z1bmNfYWNsX2RlbGV0ZV9kZWZfZmlsZT15ZXN9CnwgOiAke2Fj X2N2X2Z1bmNfYWNsX2RlbGV0ZV9mZF9ucD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNf YWNsX2RlbGV0ZV9maWxlX25wPXllc30KfCA6ICR7YWNfY3ZfZnVuY19hY2xfZnJl ZT15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfYWNsX2Zyb21fdGV4dD15ZXN9CnwgOiAk e2FjX2N2X2Z1bmNfYWNsX2dldF9mZD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfYWNs X2dldF9maWxlPXllc30KfCA6ICR7YWNfY3ZfZnVuY19hY2xfc2V0X2ZkPXllc30K fCA6ICR7YWNfY3ZfZnVuY19hY2xfc2V0X2ZpbGU9eWVzfQp8IDogJHthY19jdl9m dW5jX2FsYXJtPXllc30KfCA6ICR7YWNfY3ZfZnVuY19hbGxvY2E9eWVzfQp8IDog JHthY19jdl9mdW5jX2FyYzRyYW5kb209eWVzfQp8IDogJHthY19jdl9mdW5jX2Fy YzRyYW5kb21fYnVmPXllc30KfCA6ICR7YWNfY3ZfZnVuY19hcmM0cmFuZG9tX3Vu aWZvcm09eWVzfQp8IDogJHthY19jdl9mdW5jX2FzcHJpbnRmPXllc30KfCA6ICR7 YWNfY3ZfZnVuY19hdGV4aXQ9eWVzfQp8IDogJHthY19jdl9mdW5jX2JjbXA9eWVz fQp8IDogJHthY19jdl9mdW5jX2Jjb3B5PXllc30KfCA6ICR7YWNfY3ZfZnVuY19i aW5kcmVzdnBvcnRfc2E9eWVzfQp8IDogJHthY19jdl9mdW5jX2J0b3djPXllc30K fCA6ICR7YWNfY3ZfZnVuY19iemVybz15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfY2hv d249eWVzfQp8IDogJHthY19jdl9mdW5jX2Nsb2NrPXllc30KfCA6ICR7YWNfY3Zf ZnVuY19jbG9ja19nZXR0aW1lPXllc30KfCA6ICR7YWNfY3ZfZnVuY19jbG9zZWRp cj15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfY2xvc2Vmcm9tPXllc30KfCA6ICR7YWNf Y3ZfZnVuY19kYWVtb249eWVzfQp8IDogJHthY19jdl9mdW5jX2Rpcm5hbWU9eWVz fQp8IDogJHthY19jdl9mdW5jX2Rsb3Blbj15ZXN9CnwgOiAke2FjX2N2X2Z1bmNf ZHVwMj15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfZWFjY2Vzcz15ZXN9CnwgOiAke2Fj X2N2X2Z1bmNfZmNobW9kPXllc30KfCA6ICR7YWNfY3ZfZnVuY19mY2hvd249eWVz fQp8IDogJHthY19jdl9mdW5jX2ZjbnRsPXllc30KfCA6ICR7YWNfY3ZfZnVuY19m aWxlbm89eWVzfQp8IDogJHthY19jdl9mdW5jX2Zvcms9eWVzfQp8IDogJHthY19j dl9mdW5jX2ZwdXJnZT15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfZnJlZWFkZHJpbmZv PXllc30KfCA6ICR7YWNfY3ZfZnVuY19mc3RhdHZmcz15ZXN9CnwgOiAke2FjX2N2 X2Z1bmNfZnN5bmM9eWVzfQp8IDogJHthY19jdl9mdW5jX2Z1dGltZXM9eWVzfQp8 IDogJHthY19jdl9mdW5jX2Z3cHJpbnRmPXllc30KfCA6ICR7YWNfY3ZfZnVuY19n YWlfc3RyZXJyb3I9eWVzfQp8IDogJHthY19jdl9mdW5jX2dldGFkZHJpbmZvPXll c30KfCA6ICR7YWNfY3ZfZnVuY19nZXRjd2Q9eWVzfQp8IDogJHthY19jdl9mdW5j X2dldGRlbGltPXllc30KfCA6ICR7YWNfY3ZfZnVuY19nZXRkdGFibGVzaXplPXll c30KfCA6ICR7YWNfY3ZfZnVuY19nZXRlZ2lkPXllc30KfCA6ICR7YWNfY3ZfZnVu Y19nZXRldWlkPXllc30KfCA6ICR7YWNfY3ZfZnVuY19nZXRnaWQ9eWVzfQp8IDog JHthY19jdl9mdW5jX2dldGdyb3VwbGlzdD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNf Z2V0aG9zdGJ5bmFtZT15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfZ2V0aG9zdG5hbWU9 eWVzfQp8IDogJHthY19jdl9mdW5jX2dldGxpbmU9eWVzfQp8IDogJHthY19jdl9m dW5jX2dldG5hbWVpbmZvPXllc30KfCA6ICR7YWNfY3ZfZnVuY19nZXRvcHQ9eWVz fQp8IDogJHthY19jdl9mdW5jX2dldG9wdF9sb25nX29ubHk9eWVzfQp8IDogJHth Y19jdl9mdW5jX2dldHBhZ2VzaXplPXllc30KfCA6ICR7YWNfY3ZfZnVuY19nZXRw ZWVyZWlkPXllc30KfCA6ICR7YWNfY3ZfZnVuY19nZXRwZ2lkPXllc30KfCA6ICR7 YWNfY3ZfZnVuY19nZXRwZ3JwPXllc30KfCA6ICR7YWNfY3ZfZnVuY19nZXRwZ3Jw X3ZvaWQ9eWVzfQp8IDogJHthY19jdl9mdW5jX2dldHBpZD15ZXN9CnwgOiAke2Fj X2N2X2Z1bmNfZ2V0cmxpbWl0PXllc30KfCA6ICR7YWNfY3ZfZnVuY19nZXRydXNh Z2U9eWVzfQp8IDogJHthY19jdl9mdW5jX2dldHRpbWVvZmRheT15ZXN9CnwgOiAk e2FjX2N2X2Z1bmNfZ2V0dHR5ZW50PXllc30KfCA6ICR7YWNfY3ZfZnVuY19nZXR1 aWQ9eWVzfQp8IDogJHthY19jdl9mdW5jX2dldHdkPXllc30KfCA6ICR7YWNfY3Zf ZnVuY19nbG9iPXllc30KfCA6ICR7YWNfY3ZfZnVuY19ncm91cF9mcm9tX2dpZD15 ZXN9CnwgOiAke2FjX2N2X2Z1bmNfaW5ldF9hdG9uPXllc30KfCA6ICR7YWNfY3Zf ZnVuY19pbmV0X250b2E9eWVzfQp8IDogJHthY19jdl9mdW5jX2luZXRfbnRvcD15 ZXN9CnwgOiAke2FjX2N2X2Z1bmNfaW5uZXRncj15ZXN9CnwgOiAke2FjX2N2X2Z1 bmNfaXNhc2NpaT15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfaXNhc2NpaT15ZXN9Cnwg OiAke2FjX2N2X2Z1bmNfaXNibGFuaz15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfaXNz ZXR1Z2lkPXllc30KfCA6ICR7YWNfY3ZfZnVuY19pc3dibGFuaz15ZXN9CnwgOiAk e2FjX2N2X2Z1bmNfaXN3Y250cmw9eWVzfQp8IDogJHthY19jdl9mdW5jX2lzd2N0 eXBlPXllc30KfCA6ICR7YWNfY3ZfZnVuY19saW5rPXllc30KfCA6ICR7YWNfY3Zf ZnVuY19sb2NhbHRpbWU9eWVzfQp8IDogJHthY19jdl9mdW5jX2xzdGF0PXllc30K fCA6ICR7YWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1s aW5rPXllc30KfCA6ICR7YWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxsPXllc30K fCA6ICR7YWNfY3ZfZnVuY19tYnJsZW49eWVzfQp8IDogJHthY19jdl9mdW5jX21i cnRvd2M9eWVzfQp8IDogJHthY19jdl9mdW5jX21ic2luaXQ9eWVzfQp8IDogJHth Y19jdl9mdW5jX21ic3J0b3djcz15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfbWVtY2hy PXllc30KfCA6ICR7YWNfY3ZfZnVuY19tZW1jbXA9eWVzfQp8IDogJHthY19jdl9m dW5jX21lbWNweT15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfbWVtbW92ZT15ZXN9Cnwg OiAke2FjX2N2X2Z1bmNfbWVtc2V0PXllc30KfCA6ICR7YWNfY3ZfZnVuY19ta2R0 ZW1wPXllc30KfCA6ICR7YWNfY3ZfZnVuY19ta3N0ZW1wPXllc30KfCA6ICR7YWNf Y3ZfZnVuY19ta3RlbXA9eWVzfQp8IDogJHthY19jdl9mdW5jX21sb2NrPXllc30K fCA6ICR7YWNfY3ZfZnVuY19tbWFwPXllc30KfCA6ICR7YWNfY3ZfZnVuY19tbWFw X2ZpeGVkX21hcHBlZD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfbXByb3RlY3Q9eWVz fQp8IDogJHthY19jdl9mdW5jX211bmxvY2s9eWVzfQp8IDogJHthY19jdl9mdW5j X211bm1hcD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfbmxfbGFuZ2luZm89eWVzfQp8 IDogJHthY19jdl9mdW5jX29wZW5kaXI9eWVzfQp8IDogJHthY19jdl9mdW5jX3Bh bV9nZXRlbnZsaXN0PXllc30KfCA6ICR7YWNfY3ZfZnVuY19wYW1fcHV0ZW52PXll c30KfCA6ICR7YWNfY3ZfZnVuY19wYXRoY29uZj15ZXN9CnwgOiAke2FjX2N2X2Z1 bmNfcGlwZT15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfcG9sbD15ZXN9CnwgOiAke2Fj X2N2X2Z1bmNfcG9zaXhfc3Bhd249eWVzfQp8IDogJHthY19jdl9mdW5jX3ByZWFk PXllc30KfCA6ICR7YWNfY3ZfZnVuY19wdGhyZWFkX2NvbmRfYnJvYWRjYXN0PXll c30KfCA6ICR7YWNfY3ZfZnVuY19wdGhyZWFkX2NvbmRfZGVzdHJveT15ZXN9Cnwg OiAke2FjX2N2X2Z1bmNfcHRocmVhZF9jb25kX2luaXQ9eWVzfQp8IDogJHthY19j dl9mdW5jX3B0aHJlYWRfY29uZF9zaWduYWw9eWVzfQp8IDogJHthY19jdl9mdW5j X3B0aHJlYWRfY29uZF90aW1lZHdhaXQ9eWVzfQp8IDogJHthY19jdl9mdW5jX3B0 aHJlYWRfY29uZF93YWl0PXllc30KfCA6ICR7YWNfY3ZfZnVuY19wdGhyZWFkX2Vx dWFsPXllc30KfCA6ICR7YWNfY3ZfZnVuY19wdGhyZWFkX2V4aXQ9eWVzfQp8IDog JHthY19jdl9mdW5jX3B0aHJlYWRfbXV0ZXhfZGVzdHJveT15ZXN9CnwgOiAke2Fj X2N2X2Z1bmNfcHRocmVhZF9tdXRleF9pbml0PXllc30KfCA6ICR7YWNfY3ZfZnVu Y19wdGhyZWFkX211dGV4X2xvY2s9eWVzfQp8IDogJHthY19jdl9mdW5jX3B0aHJl YWRfbXV0ZXhfdW5sb2NrPXllc30KfCA6ICR7YWNfY3ZfZnVuY19wdGhyZWFkX3Nl bGY9eWVzfQp8IDogJHthY19jdl9mdW5jX3B1dGVudj15ZXN9CnwgOiAke2FjX2N2 X2Z1bmNfcHdyaXRlPXllc30KfCA6ICR7YWNfY3ZfZnVuY19yYWlzZT15ZXN9Cnwg OiAke2FjX2N2X2Z1bmNfcmFuZD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfcmFuZG9t PXllc30KfCA6ICR7YWNfY3ZfZnVuY19yZWFkZGlyPXllc30KfCA6ICR7YWNfY3Zf ZnVuY19yZWFkbGluaz15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfcmVhZGxpbmthdD15 ZXN9CnwgOiAke2FjX2N2X2Z1bmNfcmVhZHBhc3NwaHJhc2U9eWVzfQp8IDogJHth Y19jdl9mdW5jX3JlYWxwYXRoPXllc30KfCA6ICR7YWNfY3ZfZnVuY19yZWN2bXNn PXllc30KfCA6ICR7YWNfY3ZfZnVuY19yZW5hbWU9eWVzfQp8IDogJHthY19jdl9m dW5jX3JyZXN2cG9ydF9hZj15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc2NoZWRfeWll bGQ9eWVzfQp8IDogJHthY19jdl9mdW5jX3NlbGVjdD15ZXN9CnwgOiAke2FjX2N2 X2Z1bmNfc2VuZG1zZz15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc2V0ZWdpZD15ZXN9 CnwgOiAke2FjX2N2X2Z1bmNfc2V0ZW52PXllc30KfCA6ICR7YWNfY3ZfZnVuY19z ZXRldWlkPXllc30KfCA6ICR7YWNfY3ZfZnVuY19zZXRncm91cGVudD15ZXN9Cnwg OiAke2FjX2N2X2Z1bmNfc2V0Z3JvdXBzPXllc30KfCA6ICR7YWNfY3ZfZnVuY19z ZXRsaW5lYnVmPXllc30KfCA6ICR7YWNfY3ZfZnVuY19zZXRsb2NhbGU9eWVzfQp8 IDogJHthY19jdl9mdW5jX3NldGxvZ2luPXllc30KfCA6ICR7YWNfY3ZfZnVuY19z ZXRwYXNzZW50PXllc30KfCA6ICR7YWNfY3ZfZnVuY19zZXRwcm9jdGl0bGU9eWVz fQp8IDogJHthY19jdl9mdW5jX3NldHJlZ2lkPXllc30KfCA6ICR7YWNfY3ZfZnVu Y19zZXRyZXNnaWQ9eWVzfQp8IDogJHthY19jdl9mdW5jX3NldHJlc3VpZD15ZXN9 CnwgOiAke2FjX2N2X2Z1bmNfc2V0cmV1aWQ9eWVzfQp8IDogJHthY19jdl9mdW5j X3NldHJsaW1pdD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc2V0c2lkPXllc30KfCA6 ICR7YWNfY3ZfZnVuY19zZXRzb2Nrb3B0PXllc30KfCA6ICR7YWNfY3ZfZnVuY19z ZXR2YnVmPXllc30KfCA6ICR7YWNfY3ZfZnVuY19zaG1nZXQ9eWVzfQp8IDogJHth Y19jdl9mdW5jX3NpZ2FjdGlvbj15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc2lnYWx0 c3RhY2s9eWVzfQp8IDogJHthY19jdl9mdW5jX3NpZ2ludGVycnVwdD15ZXN9Cnwg OiAke2FjX2N2X2Z1bmNfc2lncHJvY21hc2s9eWVzfQp8IDogJHthY19jdl9mdW5j X3NpZ3ZlYz15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc2xlZXA9eWVzfQp8IDogJHth Y19jdl9mdW5jX3NucHJpbnRmPXllc30KfCA6ICR7YWNfY3ZfZnVuY19zb2NrZXRw YWlyPXllc30KfCA6ICR7YWNfY3ZfZnVuY19zcmFuZD15ZXN9CnwgOiAke2FjX2N2 X2Z1bmNfc3JhbmRvbT15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc3RhdD15ZXN9Cnwg OiAke2FjX2N2X2Z1bmNfc3RhdGZzPXllc30KfCA6ICR7YWNfY3ZfZnVuY19zdGF0 dmZzPXllc30KfCA6ICR7YWNfY3ZfZnVuY19zdHBjcHk9eWVzfQp8IDogJHthY19j dl9mdW5jX3N0cG5jcHk9eWVzfQp8IDogJHthY19jdl9mdW5jX3N0cmJyaz15ZXN9 CnwgOiAke2FjX2N2X2Z1bmNfc3RyY2FzZWNtcD15ZXN9CnwgOiAke2FjX2N2X2Z1 bmNfc3RyY3Nwbj15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc3RyZHVwPXllc30KfCA6 ICR7YWNfY3ZfZnVuY19zdHJlcnJvcj15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc3Ry ZXJyb3Jfcj15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc3RyZnRpbWU9eWVzfQp8IDog JHthY19jdl9mdW5jX3N0cmxjYXQ9eWVzfQp8IDogJHthY19jdl9mdW5jX3N0cmxj cHk9eWVzfQp8IDogJHthY19jdl9mdW5jX3N0cmxlbj15ZXN9CnwgOiAke2FjX2N2 X2Z1bmNfc3RybW9kZT15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc3RybmNhc2VjbXA9 eWVzfQp8IDogJHthY19jdl9mdW5jX3N0cm5kdXA9eWVzfQp8IDogJHthY19jdl9m dW5jX3N0cm5sZW49eWVzfQp8IDogJHthY19jdl9mdW5jX3N0cm5sZW5fd29ya2lu Zz15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc3RycGJyaz15ZXN9CnwgOiAke2FjX2N2 X2Z1bmNfc3RycHRpbWU9eWVzfQp8IDogJHthY19jdl9mdW5jX3N0cnNlcD15ZXN9 CnwgOiAke2FjX2N2X2Z1bmNfc3Ryc2lnbmFsPXllc30KfCA6ICR7YWNfY3ZfZnVu Y19zdHJ0b2w9eWVzfQp8IDogJHthY19jdl9mdW5jX3N0cnRvbGw9eWVzfQp8IDog JHthY19jdl9mdW5jX3N0cnRvbnVtPXllc30KfCA6ICR7YWNfY3ZfZnVuY19zdHJ0 b3VsPXllc30KfCA6ICR7YWNfY3ZfZnVuY19zdHJ0b3VsbD15ZXN9CnwgOiAke2Fj X2N2X2Z1bmNfc3ltbGluaz15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfc3lzY29uZj15 ZXN9CnwgOiAke2FjX2N2X2Z1bmNfdGNnZXRwZ3JwPXllc30KfCA6ICR7YWNfY3Zf ZnVuY190aW1lPXllc30KfCA6ICR7YWNfY3ZfZnVuY190b3dsb3dlcj15ZXN9Cnwg OiAke2FjX2N2X2Z1bmNfdHJ1bmNhdGU9eWVzfQp8IDogJHthY19jdl9mdW5jX3Rz ZWFyY2g9eWVzfQp8IDogJHthY19jdl9mdW5jX3VuYW1lPXllc30KfCA6ICR7YWNf Y3ZfZnVuY191bnNldGVudj15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfdXNlcl9mcm9t X3VpZD15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfdXNsZWVwPXllc30KfCA6ICR7YWNf Y3ZfZnVuY191dGltZT15ZXN9CnwgOiAke2FjX2N2X2Z1bmNfdXRpbWVzPXllc30K fCA6ICR7YWNfY3ZfZnVuY192YXNwcmludGY9eWVzfQp8IDogJHthY19jdl9mdW5j X3Zmb3JrPXllc30KfCA6ICR7YWNfY3ZfZnVuY192cHJpbnRmPXllc30KfCA6ICR7 YWNfY3ZfZnVuY192c25wcmludGY9eWVzfQp8IDogJHthY19jdl9mdW5jX3ZzcHJp bnRmPXllc30KfCA6ICR7YWNfY3ZfZnVuY193YWl0cGlkPXllc30KfCA6ICR7YWNf Y3ZfZnVuY193Y3J0b21iPXllc30KfCA6ICR7YWNfY3ZfZnVuY193Y3Njb2xsPXll c30KfCA6ICR7YWNfY3ZfZnVuY193Y3NsZW49eWVzfQp8IDogJHthY19jdl9mdW5j X3djc25sZW49eWVzfQp8IDogJHthY19jdl9mdW5jX3djdG9iPXllc30KfCA6ICR7 YWNfY3ZfZnVuY193Y3dpZHRoPXllc30KfCA6ICR7YWNfY3ZfZnVuY193bWVtY2hy PXllc30KfCA6ICR7YWNfY3ZfZnVuY193bWVtY3B5PXllc30KfCA6ICR7YWNfY3Zf ZnVuY195cF9tYXRjaD15ZXN9CnwgCnwgIyBub24gZXhpc3RpbmcgZnVuY3Rpb25z CnwgOiAke2FjX2N2X2Z1bmNfYXJnel9jb3VudD1ub30KfCA6ICR7YWNfY3ZfZnVu Y19hcmd6X25leHQ9bm99CnwgOiAke2FjX2N2X2Z1bmNfYXJnel9zdHJpbmdpZnk9 bm99CnwgOiAke2FjX2N2X2Z1bmNfb2JzdGFja3M9bm99CnwgOiAke2FjX2N2X2Z1 bmNfcHN0YXRfZ2V0ZHluYW1pYz1ub30KfCA6ICR7YWNfY3ZfZnVuY19yYXdtZW1j aHI9bm99CnwgOiAke2FjX2N2X2Z1bmNfeWllbGQ9bm99CnwgCnwgOiAke2FjX2N2 X2hhdmVfX192YV9jb3B5PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9jbG9ja190PXll c30KfCA6ICR7YWNfY3ZfaGF2ZV9jb250cm9sX2luX21zZ2hkcj15ZXN9CnwgOiAk e2FjX2N2X2hhdmVfZ2V0b3B0X29wdHJlc2V0PXllc30KfCA6ICR7YWNfY3ZfaGF2 ZV9pbnQ2NF90PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9pbnR4eF90PXllc30KfCA6 ICR7YWNfY3ZfaGF2ZV9tb2RlX3Q9eWVzfQp8IDogJHthY19jdl9oYXZlX3BpZF90 PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9wd19jaGFuZ2VfaW5fc3RydWN0X3Bhc3N3 ZD15ZXN9CnwgOiAke2FjX2N2X2hhdmVfcHdfY2xhc3NfaW5fc3RydWN0X3Bhc3N3 ZD15ZXN9CnwgOiAke2FjX2N2X2hhdmVfcHdfZXhwaXJlX2luX3N0cnVjdF9wYXNz d2Q9eWVzfQp8IDogJHthY19jdl9oYXZlX3NhX2ZhbWlseV90PXllc30KfCA6ICR7 YWNfY3ZfaGF2ZV9zaXplX3Q9eWVzfQp8IDogJHthY19jdl9oYXZlX3NzX2ZhbWls eV9pbl9zdHJ1Y3Rfc3M9eWVzfQp8IDogJHthY19jdl9oYXZlX3NzaXplX3Q9eWVz fQp8IDogJHthY19jdl9oYXZlX3N0cnVjdF9hZGRyaW5mbz15ZXN9CnwgOiAke2Fj X2N2X2hhdmVfc3RydWN0X2luNl9hZGRyPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9z dHJ1Y3Rfc29ja2FkZHJfaW42PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9zdHJ1Y3Rf c29ja2FkZHJfc3RvcmFnZT15ZXN9CnwgOiAke2FjX2N2X2hhdmVfc3RydWN0X3Rp bWV2YWw9eWVzfQp8IDogJHthY19jdl9oYXZlX3VfY2hhcj15ZXN9CnwgOiAke2Fj X2N2X2hhdmVfdV9pbnQ2NF90PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV91X2ludD15 ZXN9CnwgOiAke2FjX2N2X2hhdmVfdV9pbnR4eF90PXllc30KfCA6ICR7YWNfY3Zf aGF2ZV92YV9jb3B5PXllc30KfCAKfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX0dMT0Jf Tk9NQVRDSD15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9MTE9OR19NQVg9eWVz fQp8IDogJHthY19jdl9oYXZlX2RlY2xfTUFYU1lNTElOS1M9eWVzfQp8IDogJHth Y19jdl9oYXZlX2RlY2xfT19OT05CTE9DSz15ZXN9CnwgOiAke2FjX2N2X2hhdmVf ZGVjbF9STElNSVRfTlBST0M9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfU0hV VF9SRD15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9fRXhpdD15ZXN9CnwgOiAk e2FjX2N2X2hhdmVfZGVjbF9hbGFybT15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVj bF9hbHBoYXNvcnQ9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfYXRvbGw9eWVz fQp8IDogJHthY19jdl9oYXZlX2RlY2xfYnRvd2M9eWVzfQp8IDogJHthY19jdl9o YXZlX2RlY2xfY2hkaXI9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfY2hvd249 eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfY2xlYXJlcnJfdW5sb2NrZWQ9eWVz fQp8IDogJHthY19jdl9oYXZlX2RlY2xfY2xvc2VkaXI9eWVzfQp8IDogJHthY19j dl9oYXZlX2RlY2xfZHByaW50Zj15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9k dXAyPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX2R1cD15ZXN9CnwgOiAke2Fj X2N2X2hhdmVfZGVjbF9lbmR1c2Vyc2hlbGw9eWVzfQp8IDogJHthY19jdl9oYXZl X2RlY2xfZmFjY2Vzc2F0PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX2ZjaGRp cj15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9mY2htb2RhdD15ZXN9CnwgOiAk e2FjX2N2X2hhdmVfZGVjbF9mY2hvd25hdD15ZXN9CnwgOiAke2FjX2N2X2hhdmVf ZGVjbF9mY250bD15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9mZG9wZW5kaXI9 eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfZmVvZl91bmxvY2tlZD15ZXN9Cnwg OiAke2FjX2N2X2hhdmVfZGVjbF9mZW9mX3VubG9ja2VkX2ZnZXRzX3VubG9ja2Vk PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX2ZlcnJvcl91bmxvY2tlZD15ZXN9 CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9mZnNsPXllc30KfCA6ICR7YWNfY3ZfaGF2 ZV9kZWNsX2Zmc2xsPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX2ZwdXJnZT15 ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9mcmV4cGw9eWVzfQp8IDogJHthY19j dl9oYXZlX2RlY2xfZnNlZWtvPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX2Zz dGF0PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX2ZzdGF0YXQ9eWVzfQp8IDog JHthY19jdl9oYXZlX2RlY2xfZnN5bmM9eWVzfQp8IDogJHthY19jdl9oYXZlX2Rl Y2xfZnRlbGxvPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX2Z0cnVuY2F0ZT15 ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9nZXRjX3VubG9ja2VkPXllc30KfCA6 ICR7YWNfY3ZfaGF2ZV9kZWNsX2dldGNoYXJfdW5sb2NrZWQ9eWVzfQp8IDogJHth Y19jdl9oYXZlX2RlY2xfZ2V0Y3dkPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNs X2dldGRlbGltPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX2dldGRvbWFpbm5h bWU9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfZ2V0ZHRhYmxlc2l6ZT15ZXN9 CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9nZXRlbnY9eWVzfQp8IDogJHthY19jdl9o YXZlX2RlY2xfZ2V0Z3JvdXBzPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX2dl dGhvc3RuYW1lPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX2dldGxpbmU9eWVz fQp8IDogJHthY19jdl9oYXZlX2RlY2xfZ2V0bG9hZGF2Zz15ZXN9CnwgOiAke2Fj X2N2X2hhdmVfZGVjbF9nZXRsb2dpbj15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVj bF9nZXRsb2dpbl9yPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX2dldHBhZ2Vz aXplPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX2dldHM9eWVzfQp8IDogJHth Y19jdl9oYXZlX2RlY2xfZ2V0c3Vib3B0PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9k ZWNsX2dldHRpbWVvZmRheT15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9nZXR1 c2Vyc2hlbGw9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfZ3JhbnRwdD15ZXN9 CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9oX2Vycm5vPXllc30KfCA6ICR7YWNfY3Zf aGF2ZV9kZWNsX2ltYXhhYnM9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfaW1h eGRpdj15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9pbml0c3RhdGU9eWVzfQp8 IDogJHthY19jdl9oYXZlX2RlY2xfaXNhdHR5PXllc30KfCA6ICR7YWNfY3ZfaGF2 ZV9kZWNsX2lzYmxhbms9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfaXN3Ymxh bms9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfaXN3Y3R5cGU9eWVzfQp8IDog JHthY19jdl9oYXZlX2RlY2xfbGNobW9kPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9k ZWNsX2xjaG93bj15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9saW5rPXllc30K fCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX2xpbmthdD15ZXN9CnwgOiAke2FjX2N2X2hh dmVfZGVjbF9sc2Vlaz15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9sc3RhdD15 ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9tYnJsZW49eWVzfQp8IDogJHthY19j dl9oYXZlX2RlY2xfbWJydG93Yz15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9t YnNpbml0PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX21ic25ydG93Y3M9eWVz fQp8IDogJHthY19jdl9oYXZlX2RlY2xfbWJzcnRvd2NzPXllc30KfCA6ICR7YWNf Y3ZfaGF2ZV9kZWNsX21lbW1lbT15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9t ZW1yY2hyPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX21rZGlyYXQ9eWVzfQp8 IDogJHthY19jdl9oYXZlX2RlY2xfbWtkdGVtcD15ZXN9CnwgOiAke2FjX2N2X2hh dmVfZGVjbF9ta2ZpZm89eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfbWtmaWZv YXQ9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfbWtub2Q9eWVzfQp8IDogJHth Y19jdl9oYXZlX2RlY2xfbWtub2RhdD15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVj bF9ta3N0ZW1wPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX25sX2xhbmdpbmZv PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX29mZnNldG9mPXllc30KfCA6ICR7 YWNfY3ZfaGF2ZV9kZWNsX29wZW5hdD15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVj bF9vcGVuZGlyPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3BjbG9zZT15ZXN9 CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9waXBlPXllc30KfCA6ICR7YWNfY3ZfaGF2 ZV9kZWNsX3BvcGVuPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3Bvc2l4X29w ZW5wdD15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9wb3NpeF9zcGF3bj15ZXN9 CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9wb3NpeF9zcGF3bl9maWxlX2FjdGlvbnNf YWRkY2xvc2U9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfcG9zaXhfc3Bhd25f ZmlsZV9hY3Rpb25zX2FkZGR1cDI9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xf cG9zaXhfc3Bhd25fZmlsZV9hY3Rpb25zX2FkZG9wZW49eWVzfQp8IDogJHthY19j dl9oYXZlX2RlY2xfcG9zaXhfc3Bhd25fZmlsZV9hY3Rpb25zX2Rlc3Ryb3k9eWVz fQp8IDogJHthY19jdl9oYXZlX2RlY2xfcG9zaXhfc3Bhd25fZmlsZV9hY3Rpb25z X2luaXQ9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfcG9zaXhfc3Bhd25hdHRy X2Rlc3Ryb3k9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfcG9zaXhfc3Bhd25h dHRyX2dldGZsYWdzPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3Bvc2l4X3Nw YXduYXR0cl9nZXRwZ3JvdXA9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfcG9z aXhfc3Bhd25hdHRyX2dldHNjaGVkcGFyYW09eWVzfQp8IDogJHthY19jdl9oYXZl X2RlY2xfcG9zaXhfc3Bhd25hdHRyX2dldHNjaGVkcG9saWN5PXllc30KfCA6ICR7 YWNfY3ZfaGF2ZV9kZWNsX3Bvc2l4X3NwYXduYXR0cl9nZXRzaWdkZWZhdWx0PXll c30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3Bvc2l4X3NwYXduYXR0cl9nZXRzaWdt YXNrPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3Bvc2l4X3NwYXduYXR0cl9p bml0PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3Bvc2l4X3NwYXduYXR0cl9z ZXRmbGFncz15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9wb3NpeF9zcGF3bmF0 dHJfc2V0cGdyb3VwPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3Bvc2l4X3Nw YXduYXR0cl9zZXRzY2hlZHBhcmFtPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNs X3Bvc2l4X3NwYXduYXR0cl9zZXRzY2hlZHBvbGljeT15ZXN9CnwgOiAke2FjX2N2 X2hhdmVfZGVjbF9wb3NpeF9zcGF3bmF0dHJfc2V0c2lnZGVmYXVsdD15ZXN9Cnwg OiAke2FjX2N2X2hhdmVfZGVjbF9wb3NpeF9zcGF3bmF0dHJfc2V0c2lnbWFzaz15 ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9wb3NpeF9zcGF3bnA9eWVzfQp8IDog JHthY19jdl9oYXZlX2RlY2xfcHJlYWQ9eWVzfQp8IDogJHthY19jdl9oYXZlX2Rl Y2xfcHNlbGVjdD15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9wdGhyZWFkX3Np Z21hc2s9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfcHRzbmFtZT15ZXN9Cnwg OiAke2FjX2N2X2hhdmVfZGVjbF9wdXRjX3VubG9ja2VkPXllc30KfCA6ICR7YWNf Y3ZfaGF2ZV9kZWNsX3B1dGNoYXJfdW5sb2NrZWQ9eWVzfQp8IDogJHthY19jdl9o YXZlX2RlY2xfcHdyaXRlPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3JhbmRv bT15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9yYXdtZW1jaHI9eWVzfQp8IDog JHthY19jdl9oYXZlX2RlY2xfcmVhZGRpcj15ZXN9CnwgOiAke2FjX2N2X2hhdmVf ZGVjbF9yZWFkbGluaz15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9yZWFkbGlu a2F0PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3JlYWxwYXRoPXllc30KfCA6 ICR7YWNfY3ZfaGF2ZV9kZWNsX3JlbmFtZWF0PXllc30KfCA6ICR7YWNfY3ZfaGF2 ZV9kZWNsX3Jld2luZGRpcj15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9ybWRp cj15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9ycG1hdGNoPXllc30KfCA6ICR7 YWNfY3ZfaGF2ZV9kZWNsX3NjYW5kaXI9eWVzfQp8IDogJHthY19jdl9oYXZlX2Rl Y2xfc2VsZWN0PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3NldGVudj15ZXN9 CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9zZXRob3N0bmFtZT15ZXN9CnwgOiAke2Fj X2N2X2hhdmVfZGVjbF9zZXRsb2NhbGU9eWVzfQp8IDogJHthY19jdl9oYXZlX2Rl Y2xfc2V0c3RhdGU9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfc2V0dXNlcnNo ZWxsPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3NpZ2FjdGlvbj15ZXN9Cnwg OiAke2FjX2N2X2hhdmVfZGVjbF9zaWdhZGRzZXQ9eWVzfQp8IDogJHthY19jdl9o YXZlX2RlY2xfc2lnYWx0c3RhY2s9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xf c2lnZGVsc2V0PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3NpZ2VtcHR5c2V0 PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3NpZ2ZpbGxzZXQ9eWVzfQp8IDog JHthY19jdl9oYXZlX2RlY2xfc2lnaXNtZW1iZXI9eWVzfQp8IDogJHthY19jdl9o YXZlX2RlY2xfc2lncGVuZGluZz15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9z aWdwcm9jbWFzaz15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9zbGVlcD15ZXN9 CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9zbnByaW50Zj15ZXN9CnwgOiAke2FjX2N2 X2hhdmVfZGVjbF9zcmFuZG9tPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3N0 YXQ9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfc3RwY3B5PXllc30KfCA6ICR7 YWNfY3ZfaGF2ZV9kZWNsX3N0cG5jcHk9eWVzfQp8IDogJHthY19jdl9oYXZlX2Rl Y2xfc3RyY2FzZXN0cj15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9zdHJkdXA9 eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfc3RyZXJyb3Jfcj15ZXN9CnwgOiAk e2FjX2N2X2hhdmVfZGVjbF9zdHJuY2F0PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9k ZWNsX3N0cm5kdXA9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfc3Rybmxlbj15 ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9zdHJwYnJrPXllc30KfCA6ICR7YWNf Y3ZfaGF2ZV9kZWNsX3N0cnNlcD15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9z dHJzaWduYWw9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfc3RydG9kPXllc30K fCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3N0cnRvaW1heD15ZXN9CnwgOiAke2FjX2N2 X2hhdmVfZGVjbF9zdHJ0b2tfcj15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9z dHJ0b2xsPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3N0cnRvdWxsPXllc30K fCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3N0cnRvdW1heD15ZXN9CnwgOiAke2FjX2N2 X2hhdmVfZGVjbF9zeW1saW5rPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3N5 bWxpbmthdD15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF9zeXNfc2lnbGlzdD15 ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF90Y3NlbmRicmVhaz15ZXN9CnwgOiAk e2FjX2N2X2hhdmVfZGVjbF90bXBmaWxlPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9k ZWNsX3Rvd2N0cmFucz15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF90dHluYW1l X3I9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfdW5saW5rPXllc30KfCA6ICR7 YWNfY3ZfaGF2ZV9kZWNsX3VubGlua2F0PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9k ZWNsX3VubG9ja3B0PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3Vuc2V0ZW52 PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3VzbGVlcD15ZXN9CnwgOiAke2Fj X2N2X2hhdmVfZGVjbF92ZHByaW50Zj15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVj bF92c25wcmludGY9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfd2FpdHBpZD15 ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF93Y3BjcHk9eWVzfQp8IDogJHthY19j dl9oYXZlX2RlY2xfd2NwbmNweT15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF93 Y3J0b21iPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3djc2Nhc2VjbXA9eWVz fQp8IDogJHthY19jdl9oYXZlX2RlY2xfd2NzY2F0PXllc30KfCA6ICR7YWNfY3Zf aGF2ZV9kZWNsX3djc2Nocj15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF93Y3Nj bXA9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfd2NzY29sbD15ZXN9CnwgOiAk e2FjX2N2X2hhdmVfZGVjbF93Y3NjcHk9eWVzfQp8IDogJHthY19jdl9oYXZlX2Rl Y2xfd2NzY3Nwbj15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF93Y3NkdXA9eWVz fQp8IDogJHthY19jdl9oYXZlX2RlY2xfd2NzbGVuPXllc30KfCA6ICR7YWNfY3Zf aGF2ZV9kZWNsX3djc25jYXNlY21wPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNs X3djc25jYXQ9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfd2NzbmNtcD15ZXN9 CnwgOiAke2FjX2N2X2hhdmVfZGVjbF93Y3NuY3B5PXllc30KfCA6ICR7YWNfY3Zf aGF2ZV9kZWNsX3djc25sZW49eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfd2Nz bnJ0b21icz15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF93Y3NwYnJrPXllc30K fCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3djc3JjaHI9eWVzfQp8IDogJHthY19jdl9o YXZlX2RlY2xfd2NzcnRvbWJzPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3dj c3Nwbj15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF93Y3NzdHI9eWVzfQp8IDog JHthY19jdl9oYXZlX2RlY2xfd2NzdG9rPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9k ZWNsX3djc3dpZHRoPXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9kZWNsX3djc3hmcm09 eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfd2N0b2I9eWVzfQp8IDogJHthY19j dl9oYXZlX2RlY2xfd2N0cmFucz15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF93 Y3R5cGU9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfd2N3aWR0aD15ZXN9Cnwg OiAke2FjX2N2X2hhdmVfZGVjbF93bWVtY2hyPXllc30KfCA6ICR7YWNfY3ZfaGF2 ZV9kZWNsX3dtZW1jbXA9eWVzfQp8IDogJHthY19jdl9oYXZlX2RlY2xfd21lbWNw eT15ZXN9CnwgOiAke2FjX2N2X2hhdmVfZGVjbF93bWVtbW92ZT15ZXN9CnwgOiAk e2FjX2N2X2hhdmVfZGVjbF93bWVtc2V0PXllc30KfCA6ICR7YWNfY3ZfaGF2ZV9k ZWNsX3dyaXRldj15ZXN9CnwgCnwgIyBmdW5jdGlvbiBzcGVjaWZpYwp8IAp8IDog JHtnbF9jdl9mdW5jX2J0b3djX2VvZj15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfYnRv d2NfbnVsPXllc30KfCA6ICR7Z2xfY3ZfZnVuY19mY250bF9mX2R1cGZkX2Nsb2V4 ZWM9eWVzfQp8IDogJHtnbF9jdl9mdW5jX2ZubWF0Y2hfcG9zaXg9eWVzfQp8IDog JHtnbF9jdl9mdW5jX2ZvcGVuX3NsYXNoPXllc30KfCA6ICR7Z2xfY3ZfZnVuY19m cmV4cF9ub19saWJtPXllc30KfCA6ICR7Z2xfY3ZfZnVuY19mc2Vla289eWVzfQp8 IDogJHtnbF9jdl9mdW5jX2Z0ZWxsbz15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfZ2V0 Y3dkX251bGw9eWVzfQp8IDogJHtnbF9jdl9mdW5jX2dldGN3ZF9wb3NpeF9zaWdu YXR1cmU9eWVzfQp8IDogJHtnbF9jdl9mdW5jX2dldG9wdF9wb3NpeD15ZXN9Cnwg OiAke2dsX2N2X2Z1bmNfaXNuYW5kX25vX2xpYm09eWVzfQp8IDogJHtnbF9jdl9m dW5jX2xkZXhwX25vX2xpYm09eWVzfQp8IDogJHtnbF9jdl9mdW5jX2xzZWVrX3Bp cGU9eWVzfQp8IDogJHtnbF9jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFz aGVkX3N5bWxpbms9eWVzfQp8IDogJHtnbF9jdl9mdW5jX21hbGxvY18wX25vbm51 bGw9MX0KfCA6ICR7Z2xfY3ZfZnVuY19tYWxsb2NfcG9zaXg9eWVzfQp8IDogJHtn bF9jdl9mdW5jX21icnRvd2NfaW5jb21wbGV0ZV9zdGF0ZT15ZXN9CnwgOiAke2ds X2N2X2Z1bmNfbWJydG93Y19udWxfcmV0dmFsPXllc30KfCA6ICR7Z2xfY3ZfZnVu Y19tYnJ0b3djX251bGxfYXJnMT15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfbWJydG93 Y19udWxsX2FyZzI9eWVzfQp8IDogJHtnbF9jdl9mdW5jX21icnRvd2NfcmV0dmFs PXllc30KfCA6ICR7Z2xfY3ZfZnVuY19tYnJ0b3djX3Nhbml0eWNoZWNrPXllc30K fCA6ICR7Z2xfY3ZfZnVuY19vcGVuX3NsYXNoPXllc30KfCA6ICR7Z2xfY3ZfZnVu Y19wcmludGZfZGlyZWN0aXZlX2E9eWVzfQp8IDogJHtnbF9jdl9mdW5jX3ByaW50 Zl9kaXJlY3RpdmVfZj15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfcHJpbnRmX2RpcmVj dGl2ZV9scz15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfcHJpbnRmX2RpcmVjdGl2ZV9u PXllc30KfCA6ICR7Z2xfY3ZfZnVuY19wcmludGZfZmxhZ19ncm91cGluZz15ZXN9 CnwgOiAke2dsX2N2X2Z1bmNfcHJpbnRmX2ZsYWdfbGVmdGFkanVzdD15ZXN9Cnwg OiAke2dsX2N2X2Z1bmNfcHJpbnRmX2ZsYWdfemVybz15ZXN9CnwgOiAke2dsX2N2 X2Z1bmNfcHJpbnRmX2luZmluaXRlPXllc30KfCA6ICR7Z2xfY3ZfZnVuY19wcmlu dGZfbG9uZ19kb3VibGU9eWVzfQp8IDogJHtnbF9jdl9mdW5jX3ByaW50Zl9wb3Np dGlvbnM9eWVzfQp8IDogJHtnbF9jdl9mdW5jX3ByaW50Zl9wcmVjaXNpb249eWVz fQp8IDogJHtnbF9jdl9mdW5jX3ByaW50Zl9zaXplc19jOTk9eWVzfQp8IDogJHtn bF9jdl9mdW5jX3NpZ3Byb2NtYXNrPTF9CnwgOiAke2dsX2N2X2Z1bmNfc25wcmlu dGZfcmV0dmFsX2M5OT15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfc25wcmludGZfc2l6 ZTE9eWVzfQp8IDogJHtnbF9jdl9mdW5jX3NucHJpbnRmX3VzYWJsZT15ZXN9Cnwg OiAke2dsX2N2X2Z1bmNfc3Bhd25hdHRyX3NldHNjaGVkcGFyYW09eWVzfQp8IDog JHtnbF9jdl9mdW5jX3NwYXduYXR0cl9zZXRzY2hlZHBvbGljeT15ZXN9CnwgOiAk e2dsX2N2X2Z1bmNfc3RhdF9kaXJfc2xhc2g9eWVzfQp8IDogJHtnbF9jdl9mdW5j X3N0YXRfZmlsZV9zbGFzaD15ZXN9CnwgOiAke2dsX2N2X2Z1bmNfc3RwbmNweT15 ZXN9CnwgOiAke2dsX2N2X2Z1bmNfdmFfY29weT15ZXN9CnwgOiAke2dsX2N2X2Z1 bmNfd2NydG9tYl9yZXR2YWw9eWVzfQp8IDogJHtndF9jdl9mdW5jX3Vuc2V0ZW52 X3JldD1pbnR9CnwgCnwgOiAke2dsX2N2X2hhdmVfaW5jbHVkZV9uZXh0PXllc30K fCAKfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9yYXdtZW1jaHI9eWVzfQp8IDog JHtnbF9jdl9oYXZlX3Jhd19kZWNsX19FeGl0PXllc30KfCA6ICR7Z2xfY3ZfaGF2 ZV9yYXdfZGVjbF9hbHBoYXNvcnQ9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19k ZWNsX2F0b2xsPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9idG93Yz15 ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfY2hkaXI9eWVzfQp8IDogJHtn bF9jdl9oYXZlX3Jhd19kZWNsX2Nob3duPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9y YXdfZGVjbF9jbG9zZWRpcj15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xf ZHByaW50Zj15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfZHVwMj15ZXN9 CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfZHVwPXllc30KfCA6ICR7Z2xfY3Zf aGF2ZV9yYXdfZGVjbF9lbmR1c2Vyc2hlbGw9eWVzfQp8IDogJHtnbF9jdl9oYXZl X3Jhd19kZWNsX2ZhY2Nlc3NhdD15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2Rl Y2xfZmNoZGlyPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9mY2htb2Rh dD15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfZmNob3duYXQ9eWVzfQp8 IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX2ZjbnRsPXllc30KfCA6ICR7Z2xfY3Zf aGF2ZV9yYXdfZGVjbF9mZG9wZW5kaXI9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jh d19kZWNsX2Zmc2w9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX2Zmc2xs PXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9mcHVyZ2U9eWVzfQp8IDog JHtnbF9jdl9oYXZlX3Jhd19kZWNsX2ZzZWVrbz15ZXN9CnwgOiAke2dsX2N2X2hh dmVfcmF3X2RlY2xfZnN0YXQ9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNs X2ZzdGF0YXQ9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX2ZzeW5jPXll c30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9mdGVsbG89eWVzfQp8IDogJHtn bF9jdl9oYXZlX3Jhd19kZWNsX2Z0cnVuY2F0ZT15ZXN9CnwgOiAke2dsX2N2X2hh dmVfcmF3X2RlY2xfZ2V0Y3dkPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVj bF9nZXRkZWxpbT15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfZ2V0ZG9t YWlubmFtZT15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfZ2V0ZHRhYmxl c2l6ZT15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfZ2V0Z3JvdXBzPXll c30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9nZXRkdGFibGVzaXplPXllc30K fCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9nZXRncm91cHM9eWVzfQp8IDogJHtn bF9jdl9oYXZlX3Jhd19kZWNsX2dldGhvc3RuYW1lPXllc30KfCA6ICR7Z2xfY3Zf aGF2ZV9yYXdfZGVjbF9nZXRsaW5lPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdf ZGVjbF9nZXRsb2FkYXZnPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9n ZXRsb2dpbj15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfZ2V0bG9naW5f cj15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfZ2V0cGFnZXNpemU9eWVz fQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX2dldHM9eWVzfQp8IDogJHtnbF9j dl9oYXZlX3Jhd19kZWNsX2dldHN1Ym9wdD15ZXN9CnwgOiAke2dsX2N2X2hhdmVf cmF3X2RlY2xfZ2V0dGltZW9mZGF5PXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdf ZGVjbF9nZXR1c2Vyc2hlbGw9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNs X2dyYW50cHQ9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX2ltYXhhYnM9 eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX2ltYXhkaXY9eWVzfQp8IDog JHtnbF9jdl9oYXZlX3Jhd19kZWNsX2luaXRzdGF0ZT15ZXN9CnwgOiAke2dsX2N2 X2hhdmVfcmF3X2RlY2xfaXNhdHR5PXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdf ZGVjbF9pc3djdHlwZT15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfbGNo bW9kPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9sY2hvd249eWVzfQp8 IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX2xpbms9eWVzfQp8IDogJHtnbF9jdl9o YXZlX3Jhd19kZWNsX2xpbmthdD15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2Rl Y2xfbHNlZWs9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX2xzdGF0PXll c30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9tYnJsZW49eWVzfQp8IDogJHtn bF9jdl9oYXZlX3Jhd19kZWNsX21icnRvd2M9eWVzfQp8IDogJHtnbF9jdl9oYXZl X3Jhd19kZWNsX21ic2luaXQ9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNs X21ic25ydG93Y3M9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX21ic3J0 b3djcz15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfbWtkaXJhdD15ZXN9 CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfbWtkdGVtcD15ZXN9CnwgOiAke2ds X2N2X2hhdmVfcmF3X2RlY2xfbWtmaWZvPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9y YXdfZGVjbF9ta2ZpZm9hdD15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xf bWtub2Q9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX21rbm9kYXQ9eWVz fQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX21rc3RlbXA9eWVzfQp8IDogJHtn bF9jdl9oYXZlX3Jhd19kZWNsX25sX2xhbmdpbmZvPXllc30KfCA6ICR7Z2xfY3Zf aGF2ZV9yYXdfZGVjbF9vcGVuYXQ9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19k ZWNsX29wZW5kaXI9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3BjbG9z ZT15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfcGlwZT15ZXN9CnwgOiAk e2dsX2N2X2hhdmVfcmF3X2RlY2xfcG9wZW49eWVzfQp8IDogJHtnbF9jdl9oYXZl X3Jhd19kZWNsX3Bvc2l4X29wZW5wdD15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3 X2RlY2xfcG9zaXhfc3Bhd249eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNs X3Bvc2l4X29wZW5wdD15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfcG9z aXhfc3Bhd249eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3Bvc2l4X3Nw YXduX2ZpbGVfYWN0aW9uc19hZGRjbG9zZT15ZXN9CnwgOiAke2dsX2N2X2hhdmVf cmF3X2RlY2xfcG9zaXhfc3Bhd25fZmlsZV9hY3Rpb25zX2FkZGR1cDI9eWVzfQp8 IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3Bvc2l4X3NwYXduX2ZpbGVfYWN0aW9u c19hZGRvcGVuPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9wb3NpeF9z cGF3bl9maWxlX2FjdGlvbnNfZGVzdHJveT15ZXN9CnwgOiAke2dsX2N2X2hhdmVf cmF3X2RlY2xfcG9zaXhfc3Bhd25fZmlsZV9hY3Rpb25zX2luaXQ9eWVzfQp8IDog JHtnbF9jdl9oYXZlX3Jhd19kZWNsX3Bvc2l4X3NwYXduYXR0cl9kZXN0cm95PXll c30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9wb3NpeF9zcGF3bmF0dHJfZ2V0 ZmxhZ3M9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3Bvc2l4X3NwYXdu YXR0cl9nZXRwZ3JvdXA9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3Bv c2l4X3NwYXduYXR0cl9nZXRzY2hlZHBhcmFtPXllc30KfCA6ICR7Z2xfY3ZfaGF2 ZV9yYXdfZGVjbF9wb3NpeF9zcGF3bmF0dHJfZ2V0c2NoZWRwb2xpY3k9eWVzfQp8 IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3Bvc2l4X3NwYXduYXR0cl9nZXRzaWdk ZWZhdWx0PXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9wb3NpeF9zcGF3 bmF0dHJfZ2V0c2lnbWFzaz15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xf cG9zaXhfc3Bhd25hdHRyX2luaXQ9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19k ZWNsX3Bvc2l4X3NwYXduYXR0cl9zZXRmbGFncz15ZXN9CnwgOiAke2dsX2N2X2hh dmVfcmF3X2RlY2xfcG9zaXhfc3Bhd25hdHRyX3NldHBncm91cD15ZXN9CnwgOiAk e2dsX2N2X2hhdmVfcmF3X2RlY2xfcG9zaXhfc3Bhd25hdHRyX3NldHNjaGVkcGFy YW09eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3Bvc2l4X3NwYXduYXR0 cl9zZXRzY2hlZHBvbGljeT15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xf cG9zaXhfc3Bhd25hdHRyX3NldHNpZ2RlZmF1bHQ9eWVzfQp8IDogJHtnbF9jdl9o YXZlX3Jhd19kZWNsX3Bvc2l4X3NwYXduYXR0cl9zZXRzaWdtYXNrPXllc30KfCA6 ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9wb3NpeF9zcGF3bnA9eWVzfQp8IDogJHtn bF9jdl9oYXZlX3Jhd19kZWNsX3ByZWFkPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9y YXdfZGVjbF9wc2VsZWN0PXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9w dGhyZWFkX3NpZ21hc2s9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3B0 c25hbWU9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3B3cml0ZT15ZXN9 CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfcmFuZG9tPXllc30KfCA6ICR7Z2xf Y3ZfaGF2ZV9yYXdfZGVjbF9yZWFkZGlyPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9y YXdfZGVjbF9yZWFkbGluaz15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xf cmVhZGxpbmthdD15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfcmVhbHBh dGg9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3JlbmFtZWF0PXllc30K fCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9yZXdpbmRkaXI9eWVzfQp8IDogJHtn bF9jdl9oYXZlX3Jhd19kZWNsX3JtZGlyPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9y YXdfZGVjbF9ycG1hdGNoPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9z Y2FuZGlyPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9zZWxlY3Q9eWVz fQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3NldGVudj15ZXN9CnwgOiAke2ds X2N2X2hhdmVfcmF3X2RlY2xfc2V0aG9zdG5hbWU9eWVzfQp8IDogJHtnbF9jdl9o YXZlX3Jhd19kZWNsX3NldGxvY2FsZT15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3 X2RlY2xfc2V0c3RhdGU9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3Nl dHVzZXJzaGVsbD15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfc2lnYWN0 aW9uPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9zaWdhZGRzZXQ9eWVz fQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3NpZ2RlbHNldD15ZXN9CnwgOiAk e2dsX2N2X2hhdmVfcmF3X2RlY2xfc2lnZW1wdHlzZXQ9eWVzfQp8IDogJHtnbF9j dl9oYXZlX3Jhd19kZWNsX3NpZ2ZpbGxzZXQ9eWVzfQp8IDogJHtnbF9jdl9oYXZl X3Jhd19kZWNsX3NpZ2lzbWVtYmVyPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdf ZGVjbF9zaWdwZW5kaW5nPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9z aWdwcm9jbWFzaz15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfc2xlZXA9 eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3NucHJpbnRmPXllc30KfCA6 ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9zcmFuZG9tPXllc30KfCA6ICR7Z2xfY3Zf aGF2ZV9yYXdfZGVjbF9zdGF0PXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVj bF9zdHJlcnJvcl9yPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9zdHJ0 b2Q9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3N0cnRvaW1heD15ZXN9 CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfc3RydG9sbD15ZXN9CnwgOiAke2ds X2N2X2hhdmVfcmF3X2RlY2xfc3RydG91bGw9eWVzfQp8IDogJHtnbF9jdl9oYXZl X3Jhd19kZWNsX3N0cnRvdW1heD15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2Rl Y2xfc3ltbGluaz15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfc3ltbGlu a2F0PXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF90bXBmaWxlPXllc30K fCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF90b3djdHJhbnM9eWVzfQp8IDogJHtn bF9jdl9oYXZlX3Jhd19kZWNsX3R0eW5hbWVfcj15ZXN9CnwgOiAke2dsX2N2X2hh dmVfcmF3X2RlY2xfdW5saW5rPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVj bF91bmxpbmthdD15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfdW5sb2Nr cHQ9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3Vuc2V0ZW52PXllc30K fCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF91c2xlZXA9eWVzfQp8IDogJHtnbF9j dl9oYXZlX3Jhd19kZWNsX3ZkcHJpbnRmPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9y YXdfZGVjbF92c25wcmludGY9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNs X3dhaXRwaWQ9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3djcGNweT15 ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfd2NwbmNweT15ZXN9CnwgOiAk e2dsX2N2X2hhdmVfcmF3X2RlY2xfd2NydG9tYj15ZXN9CnwgOiAke2dsX2N2X2hh dmVfcmF3X2RlY2xfd2NzY2FzZWNtcD15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3 X2RlY2xfd2NzY2F0PXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF93Y3Nj aHI9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3djc2NtcD15ZXN9Cnwg OiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfd2NzY29sbD15ZXN9CnwgOiAke2dsX2N2 X2hhdmVfcmF3X2RlY2xfd2NzY3B5PXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdf ZGVjbF93Y3Njc3BuPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF93Y3Nk dXA9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3djc2xlbj15ZXN9Cnwg OiAke2dsX2N2X2hhdmVfcmF3X2RlY2xfd2NzbmNhc2VjbXA9eWVzfQp8IDogJHtn bF9jdl9oYXZlX3Jhd19kZWNsX3djc25jYXQ9eWVzfQp8IDogJHtnbF9jdl9oYXZl X3Jhd19kZWNsX3djc25jbXA9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNs X3djc25jcHk9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3djc25sZW49 eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3djc25ydG9tYnM9eWVzfQp8 IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3djc3Bicms9eWVzfQp8IDogJHtnbF9j dl9oYXZlX3Jhd19kZWNsX3djc3JjaHI9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jh d19kZWNsX3djc3J0b21icz15ZXN9CnwgOiAke2dsX2N2X2hhdmVfcmF3X2RlY2xf d2Nzc3BuPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF93Y3NzdHI9eWVz fQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3djc3Rvaz15ZXN9CnwgOiAke2ds X2N2X2hhdmVfcmF3X2RlY2xfd2Nzd2lkdGg9eWVzfQp8IDogJHtnbF9jdl9oYXZl X3Jhd19kZWNsX3djc3hmcm09eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNs X3djdG9iPXllc30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF93Y3RyYW5zPXll c30KfCA6ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF93Y3R5cGU9eWVzfQp8IDogJHtn bF9jdl9oYXZlX3Jhd19kZWNsX3djd2lkdGg9eWVzfQp8IDogJHtnbF9jdl9oYXZl X3Jhd19kZWNsX3dtZW1jaHI9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNs X3dtZW1jbXA9eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3dtZW1jcHk9 eWVzfQp8IDogJHtnbF9jdl9oYXZlX3Jhd19kZWNsX3dtZW1tb3ZlPXllc30KfCA6 ICR7Z2xfY3ZfaGF2ZV9yYXdfZGVjbF93bWVtc2V0PXllc30KfCAKfCA6ICR7Z2xf Y3ZfaGVhZGVyX2Vycm5vX2hfY29tcGxldGU9eWVzfQp8IDogJHtnbF9jdl9oZWFk ZXJfaW50dHlwZXNfaD15ZXN9CnwgOiAke2dsX2N2X2hlYWRlcl9sYW5naW5mb19j b2Rlc2V0PXllc30KfCA6ICR7Z2xfY3ZfaGVhZGVyX2xhbmdpbmZvX2VyYT15ZXN9 CnwgOiAke2dsX2N2X2hlYWRlcl9sYW5naW5mb190X2ZtdF9hbXBtPXllc30KfCA6 ICR7Z2xfY3ZfaGVhZGVyX2xhbmdpbmZvX3llc2V4cHI9eWVzfQp8IDogJHtnbF9j dl9oZWFkZXJfbG9jYWxlX2hfcG9zaXgyMDAxPXllc30KfCA6ICR7Z2xfY3ZfaGVh ZGVyX3NpZ25hbF9oX1NJR1BJUEU9eWVzfQp8IDogJHtnbF9jdl9oZWFkZXJfc3Rk aW50X2g9eWVzfQp8IDogJHtnbF9jdl9oZWFkZXJfc3lzX3NlbGVjdF9oX3NlbGZj b250YWluZWQ9eWVzfQp8IApjb25maWd1cmU6MjU0MTogY2hlY2tpbmcgZm9yIGEg QlNELWNvbXBhdGlibGUgaW5zdGFsbApjb25maWd1cmU6MjYwOTogcmVzdWx0OiAv dXNyL2Jpbi9pbnN0YWxsIC1jCmNvbmZpZ3VyZToyNjIwOiBjaGVja2luZyB3aGV0 aGVyIGJ1aWxkIGVudmlyb25tZW50IGlzIHNhbmUKY29uZmlndXJlOjI2NzU6IHJl c3VsdDogeWVzCmNvbmZpZ3VyZToyODI2OiBjaGVja2luZyBmb3IgYSB0aHJlYWQt c2FmZSBta2RpciAtcApjb25maWd1cmU6Mjg2NTogcmVzdWx0OiAvYmluL21rZGly IC1wCmNvbmZpZ3VyZToyODcyOiBjaGVja2luZyBmb3IgZ2F3awpjb25maWd1cmU6 Mjg5OTogcmVzdWx0OiAvdXNyL2Jpbi9hd2sKY29uZmlndXJlOjI5MTA6IGNoZWNr aW5nIHdoZXRoZXIgbWFrZSBzZXRzICQoTUFLRSkKY29uZmlndXJlOjI5MzI6IHJl c3VsdDogeWVzCmNvbmZpZ3VyZToyOTYxOiBjaGVja2luZyB3aGV0aGVyIG1ha2Ug c3VwcG9ydHMgbmVzdGVkIHZhcmlhYmxlcwpjb25maWd1cmU6Mjk3ODogcmVzdWx0 OiB5ZXMKY29uZmlndXJlOjMxMTU6IGNoZWNraW5nIHdoZXRoZXIgbWFrZSBzdXBw b3J0cyBuZXN0ZWQgdmFyaWFibGVzCmNvbmZpZ3VyZTozMTMyOiByZXN1bHQ6IHll cwpjb25maWd1cmU6MzE0NTogY2hlY2tpbmcgd2hldGhlciB0byBlbmFibGUgbWFp bnRhaW5lci1zcGVjaWZpYyBwb3J0aW9ucyBvZiBNYWtlZmlsZXMKY29uZmlndXJl OjMxNTQ6IHJlc3VsdDogbm8KY29uZmlndXJlOjMxODY6IGNoZWNraW5nIGZvciBz dHlsZSBvZiBpbmNsdWRlIHVzZWQgYnkgbWFrZQpjb25maWd1cmU6MzIxNDogcmVz dWx0OiBHTlUKY29uZmlndXJlOjMyODU6IGNoZWNraW5nIGZvciBnY2MKY29uZmln dXJlOjMzMTI6IHJlc3VsdDogY2MKY29uZmlndXJlOjM1NDE6IGNoZWNraW5nIGZv ciBDIGNvbXBpbGVyIHZlcnNpb24KY29uZmlndXJlOjM1NTA6IGNjIC0tdmVyc2lv biA+JjUKRnJlZUJTRCBjbGFuZyB2ZXJzaW9uIDMuNy4wICh0YWdzL1JFTEVBU0Vf MzcwL2ZpbmFsIDI0NjI1NykgMjAxNTA5MDYKVGFyZ2V0OiBhcm0tLWZyZWVic2Qx MS4wLWdudWVhYmkKVGhyZWFkIG1vZGVsOiBwb3NpeApjb25maWd1cmU6MzU2MTog JD8gPSAwCmNvbmZpZ3VyZTozNTUwOiBjYyAtdiA+JjUKRnJlZUJTRCBjbGFuZyB2 ZXJzaW9uIDMuNy4wICh0YWdzL1JFTEVBU0VfMzcwL2ZpbmFsIDI0NjI1NykgMjAx NTA5MDYKVGFyZ2V0OiBhcm0tLWZyZWVic2QxMS4wLWdudWVhYmkKVGhyZWFkIG1v ZGVsOiBwb3NpeApjb25maWd1cmU6MzU2MTogJD8gPSAwCmNvbmZpZ3VyZTozNTUw OiBjYyAtViA+JjUKY2M6IGVycm9yOiBhcmd1bWVudCB0byAnLVYnIGlzIG1pc3Np bmcgKGV4cGVjdGVkIDEgdmFsdWUpCmNjOiBlcnJvcjogbm8gaW5wdXQgZmlsZXMK Y29uZmlndXJlOjM1NjE6ICQ/ID0gMQpjb25maWd1cmU6MzU1MDogY2MgLXF2ZXJz aW9uID4mNQpjYzogZXJyb3I6IHVua25vd24gYXJndW1lbnQ6ICctcXZlcnNpb24n CmNjOiBlcnJvcjogbm8gaW5wdXQgZmlsZXMKY29uZmlndXJlOjM1NjE6ICQ/ID0g MQpjb25maWd1cmU6MzU4MTogY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxl ciB3b3Jrcwpjb25maWd1cmU6MzYwMzogY2MgLU8gLXBpcGUgIC1Xbm8tZXJyb3Ig LWZuby1zdHJpY3QtYWxpYXNpbmcgICBjb25mdGVzdC5jICA+JjUKZXJyb3I6IG5v IGhhbmRsZXIgcmVnaXN0ZXJlZCBmb3IgbW9kdWxlIGZvcm1hdCAncmF3JwpmYXRh bCBlcnJvcjogZXJyb3IgaW4gYmFja2VuZDogdW5rbm93biBtb2R1bGUgZm9ybWF0 CmNjOiBlcnJvcjogY2xhbmcgZnJvbnRlbmQgY29tbWFuZCBmYWlsZWQgd2l0aCBl eGl0IGNvZGUgNzAgKHVzZSAtdiB0byBzZWUgaW52b2NhdGlvbikKRnJlZUJTRCBj bGFuZyB2ZXJzaW9uIDMuNy4wICh0YWdzL1JFTEVBU0VfMzcwL2ZpbmFsIDI0NjI1 NykgMjAxNTA5MDYKVGFyZ2V0OiBhcm0tLWZyZWVic2QxMS4wLWdudWVhYmkKVGhy ZWFkIG1vZGVsOiBwb3NpeApjYzogbm90ZTogZGlhZ25vc3RpYyBtc2c6IFBMRUFT RSBzdWJtaXQgYSBidWcgcmVwb3J0IHRvIGh0dHBzOi8vYnVncy5mcmVlYnNkLm9y Zy9zdWJtaXQvIGFuZCBpbmNsdWRlIHRoZSBjcmFzaCBiYWNrdHJhY2UsIHByZXBy b2Nlc3NlZCBzb3VyY2UsIGFuZCBhc3NvY2lhdGVkIHJ1biBzY3JpcHQuCmNjOiBu b3RlOiBkaWFnbm9zdGljIG1zZzogRXJyb3IgZ2VuZXJhdGluZyBwcmVwcm9jZXNz ZWQgc291cmNlKHMpLgpjb25maWd1cmU6MzYwNzogJD8gPSA3MApjb25maWd1cmU6 MzY0NTogcmVzdWx0OiBubwpjb25maWd1cmU6IGZhaWxlZCBwcm9ncmFtIHdhczoK fCAvKiBjb25mZGVmcy5oICovCnwgI2RlZmluZSBQQUNLQUdFX05BTUUgInBrZyIK fCAjZGVmaW5lIFBBQ0tBR0VfVEFSTkFNRSAicGtnIgp8ICNkZWZpbmUgUEFDS0FH RV9WRVJTSU9OICIxLjYuMiIKfCAjZGVmaW5lIFBBQ0tBR0VfU1RSSU5HICJwa2cg MS42LjIiCnwgI2RlZmluZSBQQUNLQUdFX0JVR1JFUE9SVCAiaHR0cHM6Ly9naXRo dWIuY29tL2ZyZWVic2QvcGtnIgp8ICNkZWZpbmUgUEFDS0FHRV9VUkwgIiIKfCAj ZGVmaW5lIFBBQ0tBR0UgInBrZyIKfCAjZGVmaW5lIFZFUlNJT04gIjEuNi4yIgp8 IC8qIGVuZCBjb25mZGVmcy5oLiAgKi8KfCAKfCBpbnQKfCBtYWluICgpCnwgewp8 IAp8ICAgOwp8ICAgcmV0dXJuIDA7CnwgfQpjb25maWd1cmU6MzY1MDogZXJyb3I6 IGluIGAvdmFyL3RtcC9wb3J0cy1idWlsZC91c3IvcG9ydHMvcG9ydHMtbWdtdC9w a2cvd29yay9wa2ctMS42LjInOgpjb25maWd1cmU6MzY1MzogZXJyb3I6IEMgY29t cGlsZXIgY2Fubm90IGNyZWF0ZSBleGVjdXRhYmxlcwpTZWUgYGNvbmZpZy5sb2cn IGZvciBtb3JlIGRldGFpbHMKCiMjIC0tLS0tLS0tLS0tLS0tLS0gIyMKIyMgQ2Fj aGUgdmFyaWFibGVzLiAjIwojIyAtLS0tLS0tLS0tLS0tLS0tICMjCgphY19jdl9j X2ludDE2X3Q9eWVzCmFjX2N2X2NfaW50MzJfdD15ZXMKYWNfY3ZfY19pbnQ2NF90 PXllcwphY19jdl9jX2ludDhfdD15ZXMKYWNfY3ZfY191aW50MTZfdD15ZXMKYWNf Y3ZfY191aW50MzJfdD15ZXMKYWNfY3ZfY191aW50NjRfdD15ZXMKYWNfY3ZfY191 aW50OF90PXllcwphY19jdl9lbnZfQ0Nfc2V0PXNldAphY19jdl9lbnZfQ0NfdmFs dWU9Y2MKYWNfY3ZfZW52X0NGTEFHU19zZXQ9c2V0CmFjX2N2X2Vudl9DRkxBR1Nf dmFsdWU9Jy1PIC1waXBlICAtV25vLWVycm9yIC1mbm8tc3RyaWN0LWFsaWFzaW5n JwphY19jdl9lbnZfQ1BQRkxBR1Nfc2V0PXNldAphY19jdl9lbnZfQ1BQRkxBR1Nf dmFsdWU9JycKYWNfY3ZfZW52X0NQUF9zZXQ9c2V0CmFjX2N2X2Vudl9DUFBfdmFs dWU9Y3BwCmFjX2N2X2Vudl9MREZMQUdTX3NldD1zZXQKYWNfY3ZfZW52X0xERkxB R1NfdmFsdWU9JycKYWNfY3ZfZW52X0xETlNfQ0ZMQUdTX3NldD0nJwphY19jdl9l bnZfTEROU19DRkxBR1NfdmFsdWU9JycKYWNfY3ZfZW52X0xETlNfTElCU19zZXQ9 JycKYWNfY3ZfZW52X0xETlNfTElCU192YWx1ZT0nJwphY19jdl9lbnZfTElCU19z ZXQ9c2V0CmFjX2N2X2Vudl9MSUJTX3ZhbHVlPScnCmFjX2N2X2Vudl9MVF9TWVNf TElCUkFSWV9QQVRIX3NldD0nJwphY19jdl9lbnZfTFRfU1lTX0xJQlJBUllfUEFU SF92YWx1ZT0nJwphY19jdl9lbnZfUEtHX0NPTkZJR19MSUJESVJfc2V0PScnCmFj X2N2X2Vudl9QS0dfQ09ORklHX0xJQkRJUl92YWx1ZT0nJwphY19jdl9lbnZfUEtH X0NPTkZJR19QQVRIX3NldD0nJwphY19jdl9lbnZfUEtHX0NPTkZJR19QQVRIX3Zh bHVlPScnCmFjX2N2X2Vudl9QS0dfQ09ORklHX3NldD0nJwphY19jdl9lbnZfUEtH X0NPTkZJR192YWx1ZT0nJwphY19jdl9lbnZfYnVpbGRfYWxpYXNfc2V0PXNldAph Y19jdl9lbnZfYnVpbGRfYWxpYXNfdmFsdWU9YXJtLXBvcnRibGQtZnJlZWJzZDEx LjAKYWNfY3ZfZW52X2hvc3RfYWxpYXNfc2V0PScnCmFjX2N2X2Vudl9ob3N0X2Fs aWFzX3ZhbHVlPScnCmFjX2N2X2Vudl90YXJnZXRfYWxpYXNfc2V0PScnCmFjX2N2 X2Vudl90YXJnZXRfYWxpYXNfdmFsdWU9JycKYWNfY3ZfZnVuY19fX2I2NF9udG9w PXllcwphY19jdl9mdW5jX19fYjY0X3B0b249eWVzCmFjX2N2X2Z1bmNfX2dldGxv bmc9eWVzCmFjX2N2X2Z1bmNfX2dldHNob3J0PXllcwphY19jdl9mdW5jX19zdGF0 PXllcwphY19jdl9mdW5jX2FjbF9jcmVhdGVfZW50cnlfbnA9eWVzCmFjX2N2X2Z1 bmNfYWNsX2RlbGV0ZV9kZWZfZmlsZT15ZXMKYWNfY3ZfZnVuY19hY2xfZGVsZXRl X2ZkX25wPXllcwphY19jdl9mdW5jX2FjbF9kZWxldGVfZmlsZV9ucD15ZXMKYWNf Y3ZfZnVuY19hY2xfZnJlZT15ZXMKYWNfY3ZfZnVuY19hY2xfZnJvbV90ZXh0PXll cwphY19jdl9mdW5jX2FjbF9nZXRfZmQ9eWVzCmFjX2N2X2Z1bmNfYWNsX2dldF9m aWxlPXllcwphY19jdl9mdW5jX2FjbF9zZXRfZmQ9eWVzCmFjX2N2X2Z1bmNfYWNs X3NldF9maWxlPXllcwphY19jdl9mdW5jX2FsYXJtPXllcwphY19jdl9mdW5jX2Fs bG9jYT15ZXMKYWNfY3ZfZnVuY19hcmM0cmFuZG9tPXllcwphY19jdl9mdW5jX2Fy YzRyYW5kb21fYnVmPXllcwphY19jdl9mdW5jX2FyYzRyYW5kb21fdW5pZm9ybT15 ZXMKYWNfY3ZfZnVuY19hcmd6X2NvdW50PW5vCmFjX2N2X2Z1bmNfYXJnel9uZXh0 PW5vCmFjX2N2X2Z1bmNfYXJnel9zdHJpbmdpZnk9bm8KYWNfY3ZfZnVuY19hc3By aW50Zj15ZXMKYWNfY3ZfZnVuY19hdGV4aXQ9eWVzCmFjX2N2X2Z1bmNfYmNtcD15 ZXMKYWNfY3ZfZnVuY19iY29weT15ZXMKYWNfY3ZfZnVuY19iaW5kcmVzdnBvcnRf c2E9eWVzCmFjX2N2X2Z1bmNfYnRvd2M9eWVzCmFjX2N2X2Z1bmNfYnplcm89eWVz CmFjX2N2X2Z1bmNfY2hvd249eWVzCmFjX2N2X2Z1bmNfY2xvY2s9eWVzCmFjX2N2 X2Z1bmNfY2xvY2tfZ2V0dGltZT15ZXMKYWNfY3ZfZnVuY19jbG9zZWRpcj15ZXMK YWNfY3ZfZnVuY19jbG9zZWZyb209eWVzCmFjX2N2X2Z1bmNfZGFlbW9uPXllcwph Y19jdl9mdW5jX2Rpcm5hbWU9eWVzCmFjX2N2X2Z1bmNfZGxvcGVuPXllcwphY19j dl9mdW5jX2R1cDI9eWVzCmFjX2N2X2Z1bmNfZWFjY2Vzcz15ZXMKYWNfY3ZfZnVu Y19mY2htb2Q9eWVzCmFjX2N2X2Z1bmNfZmNob3duPXllcwphY19jdl9mdW5jX2Zj bnRsPXllcwphY19jdl9mdW5jX2ZpbGVubz15ZXMKYWNfY3ZfZnVuY19mb3JrPXll cwphY19jdl9mdW5jX2ZwdXJnZT15ZXMKYWNfY3ZfZnVuY19mcmVlYWRkcmluZm89 eWVzCmFjX2N2X2Z1bmNfZnN0YXR2ZnM9eWVzCmFjX2N2X2Z1bmNfZnN5bmM9eWVz CmFjX2N2X2Z1bmNfZnV0aW1lcz15ZXMKYWNfY3ZfZnVuY19md3ByaW50Zj15ZXMK YWNfY3ZfZnVuY19nYWlfc3RyZXJyb3I9eWVzCmFjX2N2X2Z1bmNfZ2V0YWRkcmlu Zm89eWVzCmFjX2N2X2Z1bmNfZ2V0Y3dkPXllcwphY19jdl9mdW5jX2dldGRlbGlt PXllcwphY19jdl9mdW5jX2dldGR0YWJsZXNpemU9eWVzCmFjX2N2X2Z1bmNfZ2V0 ZWdpZD15ZXMKYWNfY3ZfZnVuY19nZXRldWlkPXllcwphY19jdl9mdW5jX2dldGdp ZD15ZXMKYWNfY3ZfZnVuY19nZXRncm91cGxpc3Q9eWVzCmFjX2N2X2Z1bmNfZ2V0 aG9zdGJ5bmFtZT15ZXMKYWNfY3ZfZnVuY19nZXRob3N0bmFtZT15ZXMKYWNfY3Zf ZnVuY19nZXRsaW5lPXllcwphY19jdl9mdW5jX2dldG5hbWVpbmZvPXllcwphY19j dl9mdW5jX2dldG9wdD15ZXMKYWNfY3ZfZnVuY19nZXRvcHRfbG9uZ19vbmx5PXll cwphY19jdl9mdW5jX2dldHBhZ2VzaXplPXllcwphY19jdl9mdW5jX2dldHBlZXJl aWQ9eWVzCmFjX2N2X2Z1bmNfZ2V0cGdpZD15ZXMKYWNfY3ZfZnVuY19nZXRwZ3Jw PXllcwphY19jdl9mdW5jX2dldHBncnBfdm9pZD15ZXMKYWNfY3ZfZnVuY19nZXRw aWQ9eWVzCmFjX2N2X2Z1bmNfZ2V0cmxpbWl0PXllcwphY19jdl9mdW5jX2dldHJ1 c2FnZT15ZXMKYWNfY3ZfZnVuY19nZXR0aW1lb2ZkYXk9eWVzCmFjX2N2X2Z1bmNf Z2V0dHR5ZW50PXllcwphY19jdl9mdW5jX2dldHVpZD15ZXMKYWNfY3ZfZnVuY19n ZXR3ZD15ZXMKYWNfY3ZfZnVuY19nbG9iPXllcwphY19jdl9mdW5jX2dyb3VwX2Zy b21fZ2lkPXllcwphY19jdl9mdW5jX2luZXRfYXRvbj15ZXMKYWNfY3ZfZnVuY19p bmV0X250b2E9eWVzCmFjX2N2X2Z1bmNfaW5ldF9udG9wPXllcwphY19jdl9mdW5j X2lubmV0Z3I9eWVzCmFjX2N2X2Z1bmNfaXNhc2NpaT15ZXMKYWNfY3ZfZnVuY19p c2JsYW5rPXllcwphY19jdl9mdW5jX2lzc2V0dWdpZD15ZXMKYWNfY3ZfZnVuY19p c3dibGFuaz15ZXMKYWNfY3ZfZnVuY19pc3djbnRybD15ZXMKYWNfY3ZfZnVuY19p c3djdHlwZT15ZXMKYWNfY3ZfZnVuY19saW5rPXllcwphY19jdl9mdW5jX2xvY2Fs dGltZT15ZXMKYWNfY3ZfZnVuY19sc3RhdD15ZXMKYWNfY3ZfZnVuY19sc3RhdF9k ZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPXllcwphY19jdl9mdW5jX21hbGxv Y18wX25vbm51bGw9eWVzCmFjX2N2X2Z1bmNfbWJybGVuPXllcwphY19jdl9mdW5j X21icnRvd2M9eWVzCmFjX2N2X2Z1bmNfbWJzaW5pdD15ZXMKYWNfY3ZfZnVuY19t YnNydG93Y3M9eWVzCmFjX2N2X2Z1bmNfbWVtY2hyPXllcwphY19jdl9mdW5jX21l bWNtcD15ZXMKYWNfY3ZfZnVuY19tZW1jcHk9eWVzCmFjX2N2X2Z1bmNfbWVtbW92 ZT15ZXMKYWNfY3ZfZnVuY19tZW1zZXQ9eWVzCmFjX2N2X2Z1bmNfbWtkdGVtcD15 ZXMKYWNfY3ZfZnVuY19ta3N0ZW1wPXllcwphY19jdl9mdW5jX21rdGVtcD15ZXMK YWNfY3ZfZnVuY19tbG9jaz15ZXMKYWNfY3ZfZnVuY19tbWFwPXllcwphY19jdl9m dW5jX21tYXBfZml4ZWRfbWFwcGVkPXllcwphY19jdl9mdW5jX21wcm90ZWN0PXll cwphY19jdl9mdW5jX211bmxvY2s9eWVzCmFjX2N2X2Z1bmNfbXVubWFwPXllcwph Y19jdl9mdW5jX25sX2xhbmdpbmZvPXllcwphY19jdl9mdW5jX29ic3RhY2tzPW5v CmFjX2N2X2Z1bmNfb3BlbmRpcj15ZXMKYWNfY3ZfZnVuY19wYW1fZ2V0ZW52bGlz dD15ZXMKYWNfY3ZfZnVuY19wYW1fcHV0ZW52PXllcwphY19jdl9mdW5jX3BhdGhj b25mPXllcwphY19jdl9mdW5jX3BpcGU9eWVzCmFjX2N2X2Z1bmNfcG9sbD15ZXMK YWNfY3ZfZnVuY19wb3NpeF9zcGF3bj15ZXMKYWNfY3ZfZnVuY19wcmVhZD15ZXMK YWNfY3ZfZnVuY19wc3RhdF9nZXRkeW5hbWljPW5vCmFjX2N2X2Z1bmNfcHRocmVh ZF9jb25kX2Jyb2FkY2FzdD15ZXMKYWNfY3ZfZnVuY19wdGhyZWFkX2NvbmRfZGVz dHJveT15ZXMKYWNfY3ZfZnVuY19wdGhyZWFkX2NvbmRfaW5pdD15ZXMKYWNfY3Zf ZnVuY19wdGhyZWFkX2NvbmRfc2lnbmFsPXllcwphY19jdl9mdW5jX3B0aHJlYWRf Y29uZF90aW1lZHdhaXQ9eWVzCmFjX2N2X2Z1bmNfcHRocmVhZF9jb25kX3dhaXQ9 eWVzCmFjX2N2X2Z1bmNfcHRocmVhZF9lcXVhbD15ZXMKYWNfY3ZfZnVuY19wdGhy ZWFkX2V4aXQ9eWVzCmFjX2N2X2Z1bmNfcHRocmVhZF9tdXRleF9kZXN0cm95PXll cwphY19jdl9mdW5jX3B0aHJlYWRfbXV0ZXhfaW5pdD15ZXMKYWNfY3ZfZnVuY19w dGhyZWFkX211dGV4X2xvY2s9eWVzCmFjX2N2X2Z1bmNfcHRocmVhZF9tdXRleF91 bmxvY2s9eWVzCmFjX2N2X2Z1bmNfcHRocmVhZF9zZWxmPXllcwphY19jdl9mdW5j X3B1dGVudj15ZXMKYWNfY3ZfZnVuY19wd3JpdGU9eWVzCmFjX2N2X2Z1bmNfcmFp c2U9eWVzCmFjX2N2X2Z1bmNfcmFuZD15ZXMKYWNfY3ZfZnVuY19yYW5kb209eWVz CmFjX2N2X2Z1bmNfcmF3bWVtY2hyPW5vCmFjX2N2X2Z1bmNfcmVhZGRpcj15ZXMK YWNfY3ZfZnVuY19yZWFkbGluaz15ZXMKYWNfY3ZfZnVuY19yZWFkbGlua2F0PXll cwphY19jdl9mdW5jX3JlYWRwYXNzcGhyYXNlPXllcwphY19jdl9mdW5jX3JlYWxw YXRoPXllcwphY19jdl9mdW5jX3JlY3Ztc2c9eWVzCmFjX2N2X2Z1bmNfcmVuYW1l PXllcwphY19jdl9mdW5jX3JyZXN2cG9ydF9hZj15ZXMKYWNfY3ZfZnVuY19zY2hl ZF95aWVsZD15ZXMKYWNfY3ZfZnVuY19zZWxlY3Q9eWVzCmFjX2N2X2Z1bmNfc2Vu ZG1zZz15ZXMKYWNfY3ZfZnVuY19zZXRlZ2lkPXllcwphY19jdl9mdW5jX3NldGVu dj15ZXMKYWNfY3ZfZnVuY19zZXRldWlkPXllcwphY19jdl9mdW5jX3NldGdyb3Vw ZW50PXllcwphY19jdl9mdW5jX3NldGdyb3Vwcz15ZXMKYWNfY3ZfZnVuY19zZXRs aW5lYnVmPXllcwphY19jdl9mdW5jX3NldGxvY2FsZT15ZXMKYWNfY3ZfZnVuY19z ZXRsb2dpbj15ZXMKYWNfY3ZfZnVuY19zZXRwYXNzZW50PXllcwphY19jdl9mdW5j X3NldHByb2N0aXRsZT15ZXMKYWNfY3ZfZnVuY19zZXRyZWdpZD15ZXMKYWNfY3Zf ZnVuY19zZXRyZXNnaWQ9eWVzCmFjX2N2X2Z1bmNfc2V0cmVzdWlkPXllcwphY19j dl9mdW5jX3NldHJldWlkPXllcwphY19jdl9mdW5jX3NldHJsaW1pdD15ZXMKYWNf Y3ZfZnVuY19zZXRzaWQ9eWVzCmFjX2N2X2Z1bmNfc2V0c29ja29wdD15ZXMKYWNf Y3ZfZnVuY19zZXR2YnVmPXllcwphY19jdl9mdW5jX3NobWdldD15ZXMKYWNfY3Zf ZnVuY19zaWdhY3Rpb249eWVzCmFjX2N2X2Z1bmNfc2lnYWx0c3RhY2s9eWVzCmFj X2N2X2Z1bmNfc2lnaW50ZXJydXB0PXllcwphY19jdl9mdW5jX3NpZ3Byb2NtYXNr PXllcwphY19jdl9mdW5jX3NpZ3ZlYz15ZXMKYWNfY3ZfZnVuY19zbGVlcD15ZXMK YWNfY3ZfZnVuY19zbnByaW50Zj15ZXMKYWNfY3ZfZnVuY19zb2NrZXRwYWlyPXll cwphY19jdl9mdW5jX3NyYW5kPXllcwphY19jdl9mdW5jX3NyYW5kb209eWVzCmFj X2N2X2Z1bmNfc3RhdD15ZXMKYWNfY3ZfZnVuY19zdGF0ZnM9eWVzCmFjX2N2X2Z1 bmNfc3RhdHZmcz15ZXMKYWNfY3ZfZnVuY19zdHBjcHk9eWVzCmFjX2N2X2Z1bmNf c3RwbmNweT15ZXMKYWNfY3ZfZnVuY19zdHJicms9eWVzCmFjX2N2X2Z1bmNfc3Ry Y2FzZWNtcD15ZXMKYWNfY3ZfZnVuY19zdHJjc3BuPXllcwphY19jdl9mdW5jX3N0 cmR1cD15ZXMKYWNfY3ZfZnVuY19zdHJlcnJvcj15ZXMKYWNfY3ZfZnVuY19zdHJl cnJvcl9yPXllcwphY19jdl9mdW5jX3N0cmZ0aW1lPXllcwphY19jdl9mdW5jX3N0 cmxjYXQ9eWVzCmFjX2N2X2Z1bmNfc3RybGNweT15ZXMKYWNfY3ZfZnVuY19zdHJs ZW49eWVzCmFjX2N2X2Z1bmNfc3RybW9kZT15ZXMKYWNfY3ZfZnVuY19zdHJuY2Fz ZWNtcD15ZXMKYWNfY3ZfZnVuY19zdHJuZHVwPXllcwphY19jdl9mdW5jX3N0cm5s ZW49eWVzCmFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nPXllcwphY19jdl9mdW5j X3N0cnBicms9eWVzCmFjX2N2X2Z1bmNfc3RycHRpbWU9eWVzCmFjX2N2X2Z1bmNf c3Ryc2VwPXllcwphY19jdl9mdW5jX3N0cnNpZ25hbD15ZXMKYWNfY3ZfZnVuY19z dHJ0b2w9eWVzCmFjX2N2X2Z1bmNfc3RydG9sbD15ZXMKYWNfY3ZfZnVuY19zdHJ0 b251bT15ZXMKYWNfY3ZfZnVuY19zdHJ0b3VsPXllcwphY19jdl9mdW5jX3N0cnRv dWxsPXllcwphY19jdl9mdW5jX3N5bWxpbms9eWVzCmFjX2N2X2Z1bmNfc3lzY29u Zj15ZXMKYWNfY3ZfZnVuY190Y2dldHBncnA9eWVzCmFjX2N2X2Z1bmNfdGltZT15 ZXMKYWNfY3ZfZnVuY190b3dsb3dlcj15ZXMKYWNfY3ZfZnVuY190cnVuY2F0ZT15 ZXMKYWNfY3ZfZnVuY190c2VhcmNoPXllcwphY19jdl9mdW5jX3VuYW1lPXllcwph Y19jdl9mdW5jX3Vuc2V0ZW52PXllcwphY19jdl9mdW5jX3VzZXJfZnJvbV91aWQ9 eWVzCmFjX2N2X2Z1bmNfdXNsZWVwPXllcwphY19jdl9mdW5jX3V0aW1lPXllcwph Y19jdl9mdW5jX3V0aW1lcz15ZXMKYWNfY3ZfZnVuY192YXNwcmludGY9eWVzCmFj X2N2X2Z1bmNfdmZvcms9eWVzCmFjX2N2X2Z1bmNfdnByaW50Zj15ZXMKYWNfY3Zf ZnVuY192c25wcmludGY9eWVzCmFjX2N2X2Z1bmNfdnNwcmludGY9eWVzCmFjX2N2 X2Z1bmNfd2FpdHBpZD15ZXMKYWNfY3ZfZnVuY193Y3J0b21iPXllcwphY19jdl9m dW5jX3djc2NvbGw9eWVzCmFjX2N2X2Z1bmNfd2NzbGVuPXllcwphY19jdl9mdW5j X3djc25sZW49eWVzCmFjX2N2X2Z1bmNfd2N0b2I9eWVzCmFjX2N2X2Z1bmNfd2N3 aWR0aD15ZXMKYWNfY3ZfZnVuY193bWVtY2hyPXllcwphY19jdl9mdW5jX3dtZW1j cHk9eWVzCmFjX2N2X2Z1bmNfeWllbGQ9bm8KYWNfY3ZfZnVuY195cF9tYXRjaD15 ZXMKYWNfY3ZfaGF2ZV9fX3ZhX2NvcHk9eWVzCmFjX2N2X2hhdmVfY2xvY2tfdD15 ZXMKYWNfY3ZfaGF2ZV9jb250cm9sX2luX21zZ2hkcj15ZXMKYWNfY3ZfaGF2ZV9k ZWNsX0dMT0JfTk9NQVRDSD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX0xMT05HX01BWD15 ZXMKYWNfY3ZfaGF2ZV9kZWNsX01BWFNZTUxJTktTPXllcwphY19jdl9oYXZlX2Rl Y2xfT19OT05CTE9DSz15ZXMKYWNfY3ZfaGF2ZV9kZWNsX1JMSU1JVF9OUFJPQz15 ZXMKYWNfY3ZfaGF2ZV9kZWNsX1NIVVRfUkQ9eWVzCmFjX2N2X2hhdmVfZGVjbF9f RXhpdD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2FsYXJtPXllcwphY19jdl9oYXZlX2Rl Y2xfYWxwaGFzb3J0PXllcwphY19jdl9oYXZlX2RlY2xfYXRvbGw9eWVzCmFjX2N2 X2hhdmVfZGVjbF9idG93Yz15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2NoZGlyPXllcwph Y19jdl9oYXZlX2RlY2xfY2hvd249eWVzCmFjX2N2X2hhdmVfZGVjbF9jbGVhcmVy cl91bmxvY2tlZD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2Nsb3NlZGlyPXllcwphY19j dl9oYXZlX2RlY2xfZHByaW50Zj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2R1cDI9eWVz CmFjX2N2X2hhdmVfZGVjbF9kdXA9eWVzCmFjX2N2X2hhdmVfZGVjbF9lbmR1c2Vy c2hlbGw9eWVzCmFjX2N2X2hhdmVfZGVjbF9mYWNjZXNzYXQ9eWVzCmFjX2N2X2hh dmVfZGVjbF9mY2hkaXI9eWVzCmFjX2N2X2hhdmVfZGVjbF9mY2htb2RhdD15ZXMK YWNfY3ZfaGF2ZV9kZWNsX2ZjaG93bmF0PXllcwphY19jdl9oYXZlX2RlY2xfZmNu dGw9eWVzCmFjX2N2X2hhdmVfZGVjbF9mZG9wZW5kaXI9eWVzCmFjX2N2X2hhdmVf ZGVjbF9mZW9mX3VubG9ja2VkPXllcwphY19jdl9oYXZlX2RlY2xfZmVvZl91bmxv Y2tlZF9mZ2V0c191bmxvY2tlZD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2ZlcnJvcl91 bmxvY2tlZD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2Zmc2w9eWVzCmFjX2N2X2hhdmVf ZGVjbF9mZnNsbD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2ZwdXJnZT15ZXMKYWNfY3Zf aGF2ZV9kZWNsX2ZyZXhwbD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2ZzZWVrbz15ZXMK YWNfY3ZfaGF2ZV9kZWNsX2ZzdGF0PXllcwphY19jdl9oYXZlX2RlY2xfZnN0YXRh dD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2ZzeW5jPXllcwphY19jdl9oYXZlX2RlY2xf ZnRlbGxvPXllcwphY19jdl9oYXZlX2RlY2xfZnRydW5jYXRlPXllcwphY19jdl9o YXZlX2RlY2xfZ2V0Y191bmxvY2tlZD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2dldGNo YXJfdW5sb2NrZWQ9eWVzCmFjX2N2X2hhdmVfZGVjbF9nZXRjd2Q9eWVzCmFjX2N2 X2hhdmVfZGVjbF9nZXRkZWxpbT15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2dldGRvbWFp bm5hbWU9eWVzCmFjX2N2X2hhdmVfZGVjbF9nZXRkdGFibGVzaXplPXllcwphY19j dl9oYXZlX2RlY2xfZ2V0ZW52PXllcwphY19jdl9oYXZlX2RlY2xfZ2V0Z3JvdXBz PXllcwphY19jdl9oYXZlX2RlY2xfZ2V0aG9zdG5hbWU9eWVzCmFjX2N2X2hhdmVf ZGVjbF9nZXRsaW5lPXllcwphY19jdl9oYXZlX2RlY2xfZ2V0bG9hZGF2Zz15ZXMK YWNfY3ZfaGF2ZV9kZWNsX2dldGxvZ2luPXllcwphY19jdl9oYXZlX2RlY2xfZ2V0 bG9naW5fcj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2dldHBhZ2VzaXplPXllcwphY19j dl9oYXZlX2RlY2xfZ2V0cz15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2dldHN1Ym9wdD15 ZXMKYWNfY3ZfaGF2ZV9kZWNsX2dldHRpbWVvZmRheT15ZXMKYWNfY3ZfaGF2ZV9k ZWNsX2dldHVzZXJzaGVsbD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2dyYW50cHQ9eWVz CmFjX2N2X2hhdmVfZGVjbF9oX2Vycm5vPXllcwphY19jdl9oYXZlX2RlY2xfaW1h eGFicz15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2ltYXhkaXY9eWVzCmFjX2N2X2hhdmVf ZGVjbF9pbml0c3RhdGU9eWVzCmFjX2N2X2hhdmVfZGVjbF9pc2F0dHk9eWVzCmFj X2N2X2hhdmVfZGVjbF9pc2JsYW5rPXllcwphY19jdl9oYXZlX2RlY2xfaXN3Ymxh bms9eWVzCmFjX2N2X2hhdmVfZGVjbF9pc3djdHlwZT15ZXMKYWNfY3ZfaGF2ZV9k ZWNsX2xjaG1vZD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2xjaG93bj15ZXMKYWNfY3Zf aGF2ZV9kZWNsX2xpbms9eWVzCmFjX2N2X2hhdmVfZGVjbF9saW5rYXQ9eWVzCmFj X2N2X2hhdmVfZGVjbF9sc2Vlaz15ZXMKYWNfY3ZfaGF2ZV9kZWNsX2xzdGF0PXll cwphY19jdl9oYXZlX2RlY2xfbWJybGVuPXllcwphY19jdl9oYXZlX2RlY2xfbWJy dG93Yz15ZXMKYWNfY3ZfaGF2ZV9kZWNsX21ic2luaXQ9eWVzCmFjX2N2X2hhdmVf ZGVjbF9tYnNucnRvd2NzPXllcwphY19jdl9oYXZlX2RlY2xfbWJzcnRvd2NzPXll cwphY19jdl9oYXZlX2RlY2xfbWVtbWVtPXllcwphY19jdl9oYXZlX2RlY2xfbWVt cmNocj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX21rZGlyYXQ9eWVzCmFjX2N2X2hhdmVf ZGVjbF9ta2R0ZW1wPXllcwphY19jdl9oYXZlX2RlY2xfbWtmaWZvPXllcwphY19j dl9oYXZlX2RlY2xfbWtmaWZvYXQ9eWVzCmFjX2N2X2hhdmVfZGVjbF9ta25vZD15 ZXMKYWNfY3ZfaGF2ZV9kZWNsX21rbm9kYXQ9eWVzCmFjX2N2X2hhdmVfZGVjbF9t a3N0ZW1wPXllcwphY19jdl9oYXZlX2RlY2xfbmxfbGFuZ2luZm89eWVzCmFjX2N2 X2hhdmVfZGVjbF9vZmZzZXRvZj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX29wZW5hdD15 ZXMKYWNfY3ZfaGF2ZV9kZWNsX29wZW5kaXI9eWVzCmFjX2N2X2hhdmVfZGVjbF9w Y2xvc2U9eWVzCmFjX2N2X2hhdmVfZGVjbF9waXBlPXllcwphY19jdl9oYXZlX2Rl Y2xfcG9wZW49eWVzCmFjX2N2X2hhdmVfZGVjbF9wb3NpeF9vcGVucHQ9eWVzCmFj X2N2X2hhdmVfZGVjbF9wb3NpeF9zcGF3bj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3Bv c2l4X3NwYXduX2ZpbGVfYWN0aW9uc19hZGRjbG9zZT15ZXMKYWNfY3ZfaGF2ZV9k ZWNsX3Bvc2l4X3NwYXduX2ZpbGVfYWN0aW9uc19hZGRkdXAyPXllcwphY19jdl9o YXZlX2RlY2xfcG9zaXhfc3Bhd25fZmlsZV9hY3Rpb25zX2FkZG9wZW49eWVzCmFj X2N2X2hhdmVfZGVjbF9wb3NpeF9zcGF3bl9maWxlX2FjdGlvbnNfZGVzdHJveT15 ZXMKYWNfY3ZfaGF2ZV9kZWNsX3Bvc2l4X3NwYXduX2ZpbGVfYWN0aW9uc19pbml0 PXllcwphY19jdl9oYXZlX2RlY2xfcG9zaXhfc3Bhd25hdHRyX2Rlc3Ryb3k9eWVz CmFjX2N2X2hhdmVfZGVjbF9wb3NpeF9zcGF3bmF0dHJfZ2V0ZmxhZ3M9eWVzCmFj X2N2X2hhdmVfZGVjbF9wb3NpeF9zcGF3bmF0dHJfZ2V0cGdyb3VwPXllcwphY19j dl9oYXZlX2RlY2xfcG9zaXhfc3Bhd25hdHRyX2dldHNjaGVkcGFyYW09eWVzCmFj X2N2X2hhdmVfZGVjbF9wb3NpeF9zcGF3bmF0dHJfZ2V0c2NoZWRwb2xpY3k9eWVz CmFjX2N2X2hhdmVfZGVjbF9wb3NpeF9zcGF3bmF0dHJfZ2V0c2lnZGVmYXVsdD15 ZXMKYWNfY3ZfaGF2ZV9kZWNsX3Bvc2l4X3NwYXduYXR0cl9nZXRzaWdtYXNrPXll cwphY19jdl9oYXZlX2RlY2xfcG9zaXhfc3Bhd25hdHRyX2luaXQ9eWVzCmFjX2N2 X2hhdmVfZGVjbF9wb3NpeF9zcGF3bmF0dHJfc2V0ZmxhZ3M9eWVzCmFjX2N2X2hh dmVfZGVjbF9wb3NpeF9zcGF3bmF0dHJfc2V0cGdyb3VwPXllcwphY19jdl9oYXZl X2RlY2xfcG9zaXhfc3Bhd25hdHRyX3NldHNjaGVkcGFyYW09eWVzCmFjX2N2X2hh dmVfZGVjbF9wb3NpeF9zcGF3bmF0dHJfc2V0c2NoZWRwb2xpY3k9eWVzCmFjX2N2 X2hhdmVfZGVjbF9wb3NpeF9zcGF3bmF0dHJfc2V0c2lnZGVmYXVsdD15ZXMKYWNf Y3ZfaGF2ZV9kZWNsX3Bvc2l4X3NwYXduYXR0cl9zZXRzaWdtYXNrPXllcwphY19j dl9oYXZlX2RlY2xfcG9zaXhfc3Bhd25wPXllcwphY19jdl9oYXZlX2RlY2xfcHJl YWQ9eWVzCmFjX2N2X2hhdmVfZGVjbF9wc2VsZWN0PXllcwphY19jdl9oYXZlX2Rl Y2xfcHRocmVhZF9zaWdtYXNrPXllcwphY19jdl9oYXZlX2RlY2xfcHRzbmFtZT15 ZXMKYWNfY3ZfaGF2ZV9kZWNsX3B1dGNfdW5sb2NrZWQ9eWVzCmFjX2N2X2hhdmVf ZGVjbF9wdXRjaGFyX3VubG9ja2VkPXllcwphY19jdl9oYXZlX2RlY2xfcHdyaXRl PXllcwphY19jdl9oYXZlX2RlY2xfcmFuZG9tPXllcwphY19jdl9oYXZlX2RlY2xf cmF3bWVtY2hyPXllcwphY19jdl9oYXZlX2RlY2xfcmVhZGRpcj15ZXMKYWNfY3Zf aGF2ZV9kZWNsX3JlYWRsaW5rPXllcwphY19jdl9oYXZlX2RlY2xfcmVhZGxpbmth dD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3JlYWxwYXRoPXllcwphY19jdl9oYXZlX2Rl Y2xfcmVuYW1lYXQ9eWVzCmFjX2N2X2hhdmVfZGVjbF9yZXdpbmRkaXI9eWVzCmFj X2N2X2hhdmVfZGVjbF9ybWRpcj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3JwbWF0Y2g9 eWVzCmFjX2N2X2hhdmVfZGVjbF9zY2FuZGlyPXllcwphY19jdl9oYXZlX2RlY2xf c2VsZWN0PXllcwphY19jdl9oYXZlX2RlY2xfc2V0ZW52PXllcwphY19jdl9oYXZl X2RlY2xfc2V0aG9zdG5hbWU9eWVzCmFjX2N2X2hhdmVfZGVjbF9zZXRsb2NhbGU9 eWVzCmFjX2N2X2hhdmVfZGVjbF9zZXRzdGF0ZT15ZXMKYWNfY3ZfaGF2ZV9kZWNs X3NldHVzZXJzaGVsbD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3NpZ2FjdGlvbj15ZXMK YWNfY3ZfaGF2ZV9kZWNsX3NpZ2FkZHNldD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3Np Z2FsdHN0YWNrPXllcwphY19jdl9oYXZlX2RlY2xfc2lnZGVsc2V0PXllcwphY19j dl9oYXZlX2RlY2xfc2lnZW1wdHlzZXQ9eWVzCmFjX2N2X2hhdmVfZGVjbF9zaWdm aWxsc2V0PXllcwphY19jdl9oYXZlX2RlY2xfc2lnaXNtZW1iZXI9eWVzCmFjX2N2 X2hhdmVfZGVjbF9zaWdwZW5kaW5nPXllcwphY19jdl9oYXZlX2RlY2xfc2lncHJv Y21hc2s9eWVzCmFjX2N2X2hhdmVfZGVjbF9zbGVlcD15ZXMKYWNfY3ZfaGF2ZV9k ZWNsX3NucHJpbnRmPXllcwphY19jdl9oYXZlX2RlY2xfc3JhbmRvbT15ZXMKYWNf Y3ZfaGF2ZV9kZWNsX3N0YXQ9eWVzCmFjX2N2X2hhdmVfZGVjbF9zdHBjcHk9eWVz CmFjX2N2X2hhdmVfZGVjbF9zdHBuY3B5PXllcwphY19jdl9oYXZlX2RlY2xfc3Ry Y2FzZXN0cj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3N0cmR1cD15ZXMKYWNfY3ZfaGF2 ZV9kZWNsX3N0cmVycm9yX3I9eWVzCmFjX2N2X2hhdmVfZGVjbF9zdHJuY2F0PXll cwphY19jdl9oYXZlX2RlY2xfc3RybmR1cD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3N0 cm5sZW49eWVzCmFjX2N2X2hhdmVfZGVjbF9zdHJwYnJrPXllcwphY19jdl9oYXZl X2RlY2xfc3Ryc2VwPXllcwphY19jdl9oYXZlX2RlY2xfc3Ryc2lnbmFsPXllcwph Y19jdl9oYXZlX2RlY2xfc3RydG9kPXllcwphY19jdl9oYXZlX2RlY2xfc3RydG9p bWF4PXllcwphY19jdl9oYXZlX2RlY2xfc3RydG9rX3I9eWVzCmFjX2N2X2hhdmVf ZGVjbF9zdHJ0b2xsPXllcwphY19jdl9oYXZlX2RlY2xfc3RydG91bGw9eWVzCmFj X2N2X2hhdmVfZGVjbF9zdHJ0b3VtYXg9eWVzCmFjX2N2X2hhdmVfZGVjbF9zeW1s aW5rPXllcwphY19jdl9oYXZlX2RlY2xfc3ltbGlua2F0PXllcwphY19jdl9oYXZl X2RlY2xfc3lzX3NpZ2xpc3Q9eWVzCmFjX2N2X2hhdmVfZGVjbF90Y3NlbmRicmVh az15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3RtcGZpbGU9eWVzCmFjX2N2X2hhdmVfZGVj bF90b3djdHJhbnM9eWVzCmFjX2N2X2hhdmVfZGVjbF90dHluYW1lX3I9eWVzCmFj X2N2X2hhdmVfZGVjbF91bmxpbms9eWVzCmFjX2N2X2hhdmVfZGVjbF91bmxpbmth dD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3VubG9ja3B0PXllcwphY19jdl9oYXZlX2Rl Y2xfdW5zZXRlbnY9eWVzCmFjX2N2X2hhdmVfZGVjbF91c2xlZXA9eWVzCmFjX2N2 X2hhdmVfZGVjbF92ZHByaW50Zj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3ZzbnByaW50 Zj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3dhaXRwaWQ9eWVzCmFjX2N2X2hhdmVfZGVj bF93Y3BjcHk9eWVzCmFjX2N2X2hhdmVfZGVjbF93Y3BuY3B5PXllcwphY19jdl9o YXZlX2RlY2xfd2NydG9tYj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3djc2Nhc2VjbXA9 eWVzCmFjX2N2X2hhdmVfZGVjbF93Y3NjYXQ9eWVzCmFjX2N2X2hhdmVfZGVjbF93 Y3NjaHI9eWVzCmFjX2N2X2hhdmVfZGVjbF93Y3NjbXA9eWVzCmFjX2N2X2hhdmVf ZGVjbF93Y3Njb2xsPXllcwphY19jdl9oYXZlX2RlY2xfd2NzY3B5PXllcwphY19j dl9oYXZlX2RlY2xfd2NzY3Nwbj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3djc2R1cD15 ZXMKYWNfY3ZfaGF2ZV9kZWNsX3djc2xlbj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3dj c25jYXNlY21wPXllcwphY19jdl9oYXZlX2RlY2xfd2NzbmNhdD15ZXMKYWNfY3Zf aGF2ZV9kZWNsX3djc25jbXA9eWVzCmFjX2N2X2hhdmVfZGVjbF93Y3NuY3B5PXll cwphY19jdl9oYXZlX2RlY2xfd2Nzbmxlbj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3dj c25ydG9tYnM9eWVzCmFjX2N2X2hhdmVfZGVjbF93Y3NwYnJrPXllcwphY19jdl9o YXZlX2RlY2xfd2NzcmNocj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3djc3J0b21icz15 ZXMKYWNfY3ZfaGF2ZV9kZWNsX3djc3Nwbj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3dj c3N0cj15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3djc3Rvaz15ZXMKYWNfY3ZfaGF2ZV9k ZWNsX3djc3dpZHRoPXllcwphY19jdl9oYXZlX2RlY2xfd2NzeGZybT15ZXMKYWNf Y3ZfaGF2ZV9kZWNsX3djdG9iPXllcwphY19jdl9oYXZlX2RlY2xfd2N0cmFucz15 ZXMKYWNfY3ZfaGF2ZV9kZWNsX3djdHlwZT15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3dj d2lkdGg9eWVzCmFjX2N2X2hhdmVfZGVjbF93bWVtY2hyPXllcwphY19jdl9oYXZl X2RlY2xfd21lbWNtcD15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3dtZW1jcHk9eWVzCmFj X2N2X2hhdmVfZGVjbF93bWVtbW92ZT15ZXMKYWNfY3ZfaGF2ZV9kZWNsX3dtZW1z ZXQ9eWVzCmFjX2N2X2hhdmVfZGVjbF93cml0ZXY9eWVzCmFjX2N2X2hhdmVfZ2V0 b3B0X29wdHJlc2V0PXllcwphY19jdl9oYXZlX2ludDY0X3Q9eWVzCmFjX2N2X2hh dmVfaW50eHhfdD15ZXMKYWNfY3ZfaGF2ZV9tb2RlX3Q9eWVzCmFjX2N2X2hhdmVf cGlkX3Q9eWVzCmFjX2N2X2hhdmVfcHdfY2hhbmdlX2luX3N0cnVjdF9wYXNzd2Q9 eWVzCmFjX2N2X2hhdmVfcHdfY2xhc3NfaW5fc3RydWN0X3Bhc3N3ZD15ZXMKYWNf Y3ZfaGF2ZV9wd19leHBpcmVfaW5fc3RydWN0X3Bhc3N3ZD15ZXMKYWNfY3ZfaGF2 ZV9zYV9mYW1pbHlfdD15ZXMKYWNfY3ZfaGF2ZV9zaXplX3Q9eWVzCmFjX2N2X2hh dmVfc3NfZmFtaWx5X2luX3N0cnVjdF9zcz15ZXMKYWNfY3ZfaGF2ZV9zc2l6ZV90 PXllcwphY19jdl9oYXZlX3N0cnVjdF9hZGRyaW5mbz15ZXMKYWNfY3ZfaGF2ZV9z dHJ1Y3RfaW42X2FkZHI9eWVzCmFjX2N2X2hhdmVfc3RydWN0X3NvY2thZGRyX2lu Nj15ZXMKYWNfY3ZfaGF2ZV9zdHJ1Y3Rfc29ja2FkZHJfc3RvcmFnZT15ZXMKYWNf Y3ZfaGF2ZV9zdHJ1Y3RfdGltZXZhbD15ZXMKYWNfY3ZfaGF2ZV91X2NoYXI9eWVz CmFjX2N2X2hhdmVfdV9pbnQ2NF90PXllcwphY19jdl9oYXZlX3VfaW50PXllcwph Y19jdl9oYXZlX3VfaW50eHhfdD15ZXMKYWNfY3ZfaGF2ZV92YV9jb3B5PXllcwph Y19jdl9oZWFkZXJfYWxsb2NhX2g9bm8KYWNfY3ZfaGVhZGVyX2FyZ3pfaD1ubwph Y19jdl9oZWFkZXJfYXJwYV9pbmV0X2g9eWVzCmFjX2N2X2hlYWRlcl9hcnBhX25h bWVzZXJfaD15ZXMKYWNfY3ZfaGVhZGVyX2J5dGVzd2FwX2g9bm8KYWNfY3ZfaGVh ZGVyX2N0eXBlX2g9eWVzCmFjX2N2X2hlYWRlcl9kaXJlbnRfaD15ZXMKYWNfY3Zf aGVhZGVyX2RsX2g9bm8KYWNfY3ZfaGVhZGVyX2RsZmNuX2g9eWVzCmFjX2N2X2hl YWRlcl9lbGZfaD15ZXMKYWNfY3ZfaGVhZGVyX2Vycm5vX2g9eWVzCmFjX2N2X2hl YWRlcl9mY250bF9oPXllcwphY19jdl9oZWFkZXJfZmxvYXRfaD15ZXMKYWNfY3Zf aGVhZGVyX2Zsb2F0aW5ncG9pbnRfaD15ZXMKYWNfY3ZfaGVhZGVyX2dldG9wdF9o PXllcwphY19jdl9oZWFkZXJfZ2xvYl9oPXllcwphY19jdl9oZWFkZXJfaW50dHlw ZXNfaD15ZXMKYWNfY3ZfaGVhZGVyX2xhbmdpbmZvX2g9eWVzCmFjX2N2X2hlYWRl cl9saWJnZW5faD15ZXMKYWNfY3ZfaGVhZGVyX2xpYnV0aWxfaD15ZXMKYWNfY3Zf aGVhZGVyX2xpbWl0c19oPXllcwphY19jdl9oZWFkZXJfbG9naW5fY2FwX2g9eWVz CmFjX2N2X2hlYWRlcl9tYWxsb2NfaD1ubwphY19jdl9oZWFkZXJfbWF0aF9oPXll cwphY19jdl9oZWFkZXJfbWVtb3J5X2g9eWVzCmFjX2N2X2hlYWRlcl9taW5peF9j b25maWdfaD1ubwphY19jdl9oZWFkZXJfbmV0X2lmX2g9eWVzCmFjX2N2X2hlYWRl cl9uZXRfaWZfbWVkaWFfaD15ZXMKYWNfY3ZfaGVhZGVyX25ldF9pZl90YXBfaD15 ZXMKYWNfY3ZfaGVhZGVyX25ldF9pZl90dW5faD15ZXMKYWNfY3ZfaGVhZGVyX25l dGRiX2g9eWVzCmFjX2N2X2hlYWRlcl9uZXRpbmV0X2luX2g9eWVzCmFjX2N2X2hl YWRlcl9wYXRoc19oPXllcwphY19jdl9oZWFkZXJfcG9sbF9oPXllcwphY19jdl9o ZWFkZXJfcHdkX2g9eWVzCmFjX2N2X2hlYWRlcl9yYW5kb21faD1ubwphY19jdl9o ZWFkZXJfcmVhZHBhc3NwaHJhc2VfaD15ZXMKYWNfY3ZfaGVhZGVyX3Jlc29sdl9o PXllcwphY19jdl9oZWFkZXJfcnBjX3R5cGVzX2g9eWVzCmFjX2N2X2hlYWRlcl9z Y2hlZF9oPXllcwphY19jdl9oZWFkZXJfc2VhcmNoX2g9eWVzCmFjX2N2X2hlYWRl cl9zZWN1cml0eV9wYW1fYXBwbF9oPXllcwphY19jdl9oZWFkZXJfc2lnbmFsX2g9 eWVzCmFjX2N2X2hlYWRlcl9zcGF3bl9oPXllcwphY19jdl9oZWFkZXJfc3RkYXJn X2g9eWVzCmFjX2N2X2hlYWRlcl9zdGRib29sX2g9eWVzCmFjX2N2X2hlYWRlcl9z dGRjPXllcwphY19jdl9oZWFkZXJfc3RkZGVmX2g9eWVzCmFjX2N2X2hlYWRlcl9z dGRpbnRfaD15ZXMKYWNfY3ZfaGVhZGVyX3N0ZGlvX2g9eWVzCmFjX2N2X2hlYWRl cl9zdGRsaWJfaD15ZXMKYWNfY3ZfaGVhZGVyX3N0cmluZ19oPXllcwphY19jdl9o ZWFkZXJfc3RyaW5nc19oPXllcwphY19jdl9oZWFkZXJfc3lzX2FjbF9oPXllcwph Y19jdl9oZWFkZXJfc3lzX2NkZWZzX2g9eWVzCmFjX2N2X2hlYWRlcl9zeXNfZGly X2g9eWVzCmFjX2N2X2hlYWRlcl9zeXNfZmNudGxfaD15ZXMKYWNfY3ZfaGVhZGVy X3N5c19maWxlX2g9eWVzCmFjX2N2X2hlYWRlcl9zeXNfaW9jdGxfaD15ZXMKYWNf Y3ZfaGVhZGVyX3N5c19tbWFuX2g9eWVzCmFjX2N2X2hlYWRlcl9zeXNfbW91bnRf aD15ZXMKYWNfY3ZfaGVhZGVyX3N5c19tc2dfaD15ZXMKYWNfY3ZfaGVhZGVyX3N5 c19wYXJhbV9oPXllcwphY19jdl9oZWFkZXJfc3lzX3BvbGxfaD15ZXMKYWNfY3Zf aGVhZGVyX3N5c19wdHJhY2VfaD15ZXMKYWNfY3ZfaGVhZGVyX3N5c19zZWxlY3Rf aD15ZXMKYWNfY3ZfaGVhZGVyX3N5c19zb2NrZXRfaD15ZXMKYWNfY3ZfaGVhZGVy X3N5c19zdGF0X2g9eWVzCmFjX2N2X2hlYWRlcl9zeXNfc3RhdHZmc19oPXllcwph Y19jdl9oZWFkZXJfc3lzX3RpbWVfaD15ZXMKYWNfY3ZfaGVhZGVyX3N5c190aW1l cnNfaD15ZXMKYWNfY3ZfaGVhZGVyX3N5c190aW1lc19oPXllcwphY19jdl9oZWFk ZXJfc3lzX3R5cGVzX2g9eWVzCmFjX2N2X2hlYWRlcl9zeXNfdW5faD15ZXMKYWNf Y3ZfaGVhZGVyX3N5c193YWl0X2g9eWVzCmFjX2N2X2hlYWRlcl90aW1lX2g9eWVz CmFjX2N2X2hlYWRlcl90dHllbnRfaD15ZXMKYWNfY3ZfaGVhZGVyX3Vjb250ZXh0 X2g9eWVzCmFjX2N2X2hlYWRlcl91bmlzdGRfaD15ZXMKYWNfY3ZfaGVhZGVyX3V0 aW1lX2g9eWVzCmFjX2N2X2hlYWRlcl92Zm9ya19oPW5vCmFjX2N2X2hlYWRlcl92 aXNfaD15ZXMKYWNfY3ZfaGVhZGVyX3djaGFyX2g9eWVzCmFjX2N2X2hlYWRlcl93 Y3R5cGVfaD15ZXMKYWNfY3ZfaGVhZGVyX3psaWJfaD15ZXMKYWNfY3ZfbGliX2Ny eXB0X2NyeXB0PXllcwphY19jdl9saWJfZWRpdF9lbF9pbml0PXllcwphY19jdl9s aWJfcGFtX3BhbV9zZXRfaXRlbT15ZXMKYWNfY3ZfbGliX3pfZGVmbGF0ZT15ZXMK YWNfY3ZfbGliY19kZWZpbmVzX19fcHJvZ25hbWU9eWVzCmFjX2N2X2xpYmNfZGVm aW5lc19zeXNfZXJybGlzdD15ZXMKYWNfY3ZfbGliY19kZWZpbmVzX3N5c19uZXJy PXllcwphY19jdl9tZW1iZXJfSEVBREVSX2FkPXllcwphY19jdl9tZW1iZXJfc3Ry dWN0X19fcmVzX3N0YXRlX3JldHJhbnM9eWVzCmFjX2N2X21lbWJlcl9zdHJ1Y3Rf c2lnYWN0aW9uX3NhX3NpZ2FjdGlvbj15ZXMKYWNfY3ZfbWVtYmVyX3N0cnVjdF9z b2NrYWRkcl9pbjZfc2luNl9zY29wZV9pZD15ZXMKYWNfY3ZfbWVtYmVyX3N0cnVj dF9zdGF0X3N0X2Jsa3NpemU9eWVzCmFjX2N2X3BhdGhfQlpJUDI9L3Vzci9iaW4v YnppcDIKYWNfY3ZfcGF0aF9FR1JFUD0vdXNyL2Jpbi9lZ3JlcAphY19jdl9wYXRo X0ZHUkVQPS91c3IvYmluL2ZncmVwCmFjX2N2X3BhdGhfR1JFUD0vdXNyL2Jpbi9n cmVwCmFjX2N2X3BhdGhfR1pJUD0vdXNyL2Jpbi9nemlwCmFjX2N2X3BhdGhfTUtU RU1QX0NPTU1BTkQ9L3Vzci9iaW4vbWt0ZW1wCmFjX2N2X3BhdGhfU0VEPS91c3Iv YmluL3NlZAphY19jdl9wYXRoX2luc3RhbGw9L3Vzci9iaW4vaW5zdGFsbAphY19j dl9wYXRoX21rZGlyPS9iaW4vbWtkaXIKYWNfY3ZfcHJvZ19BV0s9L3Vzci9iaW4v YXdrCmFjX2N2X3Byb2dfU0VEPS91c3IvYmluL3NlZAphY19jdl9wcm9nX2FjX2N0 X0NDPWNjCmFjX2N2X3Byb2dfbWFrZV9tYWtlX3NldD15ZXMKYWNfY3ZfdHlwZV9f Qm9vbD15ZXMKYWNfY3ZfdHlwZV9jaGFyPXllcwphY19jdl90eXBlX2NoYXJfcD15 ZXMKYWNfY3ZfdHlwZV9mc2Jsa2NudF90PXllcwphY19jdl90eXBlX2ZzZmlsY250 X3Q9eWVzCmFjX2N2X3R5cGVfaW5fYWRkcl90PXllcwphY19jdl90eXBlX2luX3Bv cnRfdD15ZXMKYWNfY3ZfdHlwZV9pbnQxNl90PXllcwphY19jdl90eXBlX2ludDMy X3Q9eWVzCmFjX2N2X3R5cGVfaW50PXllcwphY19jdl90eXBlX2ludG1heF90PXll cwphY19jdl90eXBlX2xvbmc9eWVzCmFjX2N2X3R5cGVfbG9uZ19kb3VibGU9eWVz CmFjX2N2X3R5cGVfbG9uZ19sb25nPXllcwphY19jdl90eXBlX2xvbmdfbG9uZ19p bnQ9eWVzCmFjX2N2X3R5cGVfbWJzdGF0ZV90PXllcwphY19jdl90eXBlX21vZGVf dD15ZXMKYWNfY3ZfdHlwZV9ubGlua190PXllcwphY19jdl90eXBlX29mZl90PXll cwphY19jdl90eXBlX3BpZF90PXllcwphY19jdl90eXBlX3Bvc2l4X3NwYXduX2Zp bGVfYWN0aW9uc190PXllcwphY19jdl90eXBlX3Bvc2l4X3NwYXduYXR0cl90PXll cwphY19jdl90eXBlX3B0cmRpZmZfdD15ZXMKYWNfY3ZfdHlwZV9zaG9ydD15ZXMK YWNfY3ZfdHlwZV9zaWdfYXRvbWljX3Q9eWVzCmFjX2N2X3R5cGVfc2lnc2V0X3Q9 eWVzCmFjX2N2X3R5cGVfc2l6ZV90PXllcwphY19jdl90eXBlX3NvY2tsZW5fdD15 ZXMKYWNfY3ZfdHlwZV9zc2l6ZV90PXllcwphY19jdl90eXBlX3N0YWNrX3Q9eWVz CmFjX2N2X3R5cGVfc3RydWN0X3RpbWVzcGVjPXllcwphY19jdl90eXBlX3VfY2hh cj15ZXMKYWNfY3ZfdHlwZV91X2ludDE2X3Q9eWVzCmFjX2N2X3R5cGVfdV9pbnQz Ml90PXllcwphY19jdl90eXBlX3VfaW50OF90PXllcwphY19jdl90eXBlX3VfaW50 PXllcwphY19jdl90eXBlX3VfbG9uZz15ZXMKYWNfY3ZfdHlwZV91X3Nob3J0PXll cwphY19jdl90eXBlX3VpZF90PXllcwphY19jdl90eXBlX3VpbnRwdHJfdD15ZXMK YWNfY3ZfdHlwZV91bnNpZ25lZF9jaGFyPXllcwphY19jdl90eXBlX3Vuc2lnbmVk X2ludD15ZXMKYWNfY3ZfdHlwZV91bnNpZ25lZF9sb25nPXllcwphY19jdl90eXBl X3Vuc2lnbmVkX2xvbmdfbG9uZz15ZXMKYWNfY3ZfdHlwZV91bnNpZ25lZF9sb25n X2xvbmdfaW50PXllcwphY19jdl90eXBlX3Vuc2lnbmVkX3Nob3J0PXllcwphY19j dl90eXBlX3ZvbGF0aWxlX3NpZ19hdG9taWNfdD15ZXMKYWNfY3ZfdHlwZV93Y2hh cl90PXllcwphY19jdl90eXBlX3dpbnRfdD15ZXMKYW1fY3ZfbWFrZV9zdXBwb3J0 X25lc3RlZF92YXJpYWJsZXM9eWVzCmFtX2N2X3Byb2dfdGFyX3VzdGFyPS91c3Iv YmluL3RhcgpjbF9jdl9wcm9nX0xOPS9iaW4vbG4KY2xfY3ZfcHJvZ19jcD0nL2Jp bi9jcCAtcCcKZ2xfY3ZfZnVuY19idG93Y19lb2Y9eWVzCmdsX2N2X2Z1bmNfYnRv d2NfbnVsPXllcwpnbF9jdl9mdW5jX2ZjbnRsX2ZfZHVwZmRfY2xvZXhlYz15ZXMK Z2xfY3ZfZnVuY19mbm1hdGNoX3Bvc2l4PXllcwpnbF9jdl9mdW5jX2ZvcGVuX3Ns YXNoPXllcwpnbF9jdl9mdW5jX2ZyZXhwX25vX2xpYm09eWVzCmdsX2N2X2Z1bmNf ZnNlZWtvPXllcwpnbF9jdl9mdW5jX2Z0ZWxsbz15ZXMKZ2xfY3ZfZnVuY19nZXRj d2RfbnVsbD15ZXMKZ2xfY3ZfZnVuY19nZXRjd2RfcG9zaXhfc2lnbmF0dXJlPXll cwpnbF9jdl9mdW5jX2dldG9wdF9wb3NpeD15ZXMKZ2xfY3ZfZnVuY19pc25hbmRf bm9fbGlibT15ZXMKZ2xfY3ZfZnVuY19sZGV4cF9ub19saWJtPXllcwpnbF9jdl9m dW5jX2xzZWVrX3BpcGU9eWVzCmdsX2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2Vz X3NsYXNoZWRfc3ltbGluaz15ZXMKZ2xfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxs PTEKZ2xfY3ZfZnVuY19tYWxsb2NfcG9zaXg9eWVzCmdsX2N2X2Z1bmNfbWJydG93 Y19pbmNvbXBsZXRlX3N0YXRlPXllcwpnbF9jdl9mdW5jX21icnRvd2NfbnVsX3Jl dHZhbD15ZXMKZ2xfY3ZfZnVuY19tYnJ0b3djX251bGxfYXJnMT15ZXMKZ2xfY3Zf ZnVuY19tYnJ0b3djX251bGxfYXJnMj15ZXMKZ2xfY3ZfZnVuY19tYnJ0b3djX3Jl dHZhbD15ZXMKZ2xfY3ZfZnVuY19tYnJ0b3djX3Nhbml0eWNoZWNrPXllcwpnbF9j dl9mdW5jX29wZW5fc2xhc2g9eWVzCmdsX2N2X2Z1bmNfcHJpbnRmX2RpcmVjdGl2 ZV9hPXllcwpnbF9jdl9mdW5jX3ByaW50Zl9kaXJlY3RpdmVfZj15ZXMKZ2xfY3Zf ZnVuY19wcmludGZfZGlyZWN0aXZlX2xzPXllcwpnbF9jdl9mdW5jX3ByaW50Zl9k aXJlY3RpdmVfbj15ZXMKZ2xfY3ZfZnVuY19wcmludGZfZmxhZ19ncm91cGluZz15 ZXMKZ2xfY3ZfZnVuY19wcmludGZfZmxhZ19sZWZ0YWRqdXN0PXllcwpnbF9jdl9m dW5jX3ByaW50Zl9mbGFnX3plcm89eWVzCmdsX2N2X2Z1bmNfcHJpbnRmX2luZmlu aXRlPXllcwpnbF9jdl9mdW5jX3ByaW50Zl9sb25nX2RvdWJsZT15ZXMKZ2xfY3Zf ZnVuY19wcmludGZfcG9zaXRpb25zPXllcwpnbF9jdl9mdW5jX3ByaW50Zl9wcmVj aXNpb249eWVzCmdsX2N2X2Z1bmNfcHJpbnRmX3NpemVzX2M5OT15ZXMKZ2xfY3Zf ZnVuY19zaWdwcm9jbWFzaz0xCmdsX2N2X2Z1bmNfc25wcmludGZfcmV0dmFsX2M5 OT15ZXMKZ2xfY3ZfZnVuY19zbnByaW50Zl9zaXplMT15ZXMKZ2xfY3ZfZnVuY19z bnByaW50Zl91c2FibGU9eWVzCmdsX2N2X2Z1bmNfc3Bhd25hdHRyX3NldHNjaGVk cGFyYW09eWVzCmdsX2N2X2Z1bmNfc3Bhd25hdHRyX3NldHNjaGVkcG9saWN5PXll cwpnbF9jdl9mdW5jX3N0YXRfZGlyX3NsYXNoPXllcwpnbF9jdl9mdW5jX3N0YXRf ZmlsZV9zbGFzaD15ZXMKZ2xfY3ZfZnVuY19zdHBuY3B5PXllcwpnbF9jdl9mdW5j X3ZhX2NvcHk9eWVzCmdsX2N2X2Z1bmNfd2NydG9tYl9yZXR2YWw9eWVzCmdsX2N2 X2hhdmVfaW5jbHVkZV9uZXh0PXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX19FeGl0 PXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX2FscGhhc29ydD15ZXMKZ2xfY3ZfaGF2 ZV9yYXdfZGVjbF9hdG9sbD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9idG93Yz15 ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9jaGRpcj15ZXMKZ2xfY3ZfaGF2ZV9yYXdf ZGVjbF9jaG93bj15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9jbG9zZWRpcj15ZXMK Z2xfY3ZfaGF2ZV9yYXdfZGVjbF9kcHJpbnRmPXllcwpnbF9jdl9oYXZlX3Jhd19k ZWNsX2R1cDI9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfZHVwPXllcwpnbF9jdl9o YXZlX3Jhd19kZWNsX2VuZHVzZXJzaGVsbD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVj bF9mYWNjZXNzYXQ9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfZmNoZGlyPXllcwpn bF9jdl9oYXZlX3Jhd19kZWNsX2ZjaG1vZGF0PXllcwpnbF9jdl9oYXZlX3Jhd19k ZWNsX2ZjaG93bmF0PXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX2ZjbnRsPXllcwpn bF9jdl9oYXZlX3Jhd19kZWNsX2Zkb3BlbmRpcj15ZXMKZ2xfY3ZfaGF2ZV9yYXdf ZGVjbF9mZnNsPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX2Zmc2xsPXllcwpnbF9j dl9oYXZlX3Jhd19kZWNsX2ZwdXJnZT15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9m c2Vla289eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfZnN0YXQ9eWVzCmdsX2N2X2hh dmVfcmF3X2RlY2xfZnN0YXRhdD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9mc3lu Yz15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9mdGVsbG89eWVzCmdsX2N2X2hhdmVf cmF3X2RlY2xfZnRydW5jYXRlPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX2dldGN3 ZD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9nZXRkZWxpbT15ZXMKZ2xfY3ZfaGF2 ZV9yYXdfZGVjbF9nZXRkb21haW5uYW1lPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNs X2dldGR0YWJsZXNpemU9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfZ2V0Z3JvdXBz PXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX2dldGhvc3RuYW1lPXllcwpnbF9jdl9o YXZlX3Jhd19kZWNsX2dldGxpbmU9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfZ2V0 bG9hZGF2Zz15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9nZXRsb2dpbj15ZXMKZ2xf Y3ZfaGF2ZV9yYXdfZGVjbF9nZXRsb2dpbl9yPXllcwpnbF9jdl9oYXZlX3Jhd19k ZWNsX2dldHBhZ2VzaXplPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX2dldHM9eWVz CmdsX2N2X2hhdmVfcmF3X2RlY2xfZ2V0c3Vib3B0PXllcwpnbF9jdl9oYXZlX3Jh d19kZWNsX2dldHRpbWVvZmRheT15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9nZXR1 c2Vyc2hlbGw9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfZ3JhbnRwdD15ZXMKZ2xf Y3ZfaGF2ZV9yYXdfZGVjbF9pbWF4YWJzPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNs X2ltYXhkaXY9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfaW5pdHN0YXRlPXllcwpn bF9jdl9oYXZlX3Jhd19kZWNsX2lzYXR0eT15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVj bF9pc3djdHlwZT15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9sY2htb2Q9eWVzCmds X2N2X2hhdmVfcmF3X2RlY2xfbGNob3duPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNs X2xpbms9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfbGlua2F0PXllcwpnbF9jdl9o YXZlX3Jhd19kZWNsX2xzZWVrPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX2xzdGF0 PXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX21icmxlbj15ZXMKZ2xfY3ZfaGF2ZV9y YXdfZGVjbF9tYnJ0b3djPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX21ic2luaXQ9 eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfbWJzbnJ0b3djcz15ZXMKZ2xfY3ZfaGF2 ZV9yYXdfZGVjbF9tYnNydG93Y3M9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfbWVt Y3B5PW5vCmdsX2N2X2hhdmVfcmF3X2RlY2xfbWVtbWVtPXllcwpnbF9jdl9oYXZl X3Jhd19kZWNsX21lbXJjaHI9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfbWtkaXJh dD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9ta2R0ZW1wPXllcwpnbF9jdl9oYXZl X3Jhd19kZWNsX21rZmlmbz15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9ta2ZpZm9h dD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9ta25vZD15ZXMKZ2xfY3ZfaGF2ZV9y YXdfZGVjbF9ta25vZGF0PXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX21rc3RlbXA9 eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfbmxfbGFuZ2luZm89eWVzCmdsX2N2X2hh dmVfcmF3X2RlY2xfb3BlbmF0PXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX29wZW5k aXI9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfcGNsb3NlPXllcwpnbF9jdl9oYXZl X3Jhd19kZWNsX3BpcGU9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfcG9wZW49eWVz CmdsX2N2X2hhdmVfcmF3X2RlY2xfcG9zaXhfb3BlbnB0PXllcwpnbF9jdl9oYXZl X3Jhd19kZWNsX3Bvc2l4X3NwYXduPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3Bv c2l4X3NwYXduX2ZpbGVfYWN0aW9uc19hZGRjbG9zZT15ZXMKZ2xfY3ZfaGF2ZV9y YXdfZGVjbF9wb3NpeF9zcGF3bl9maWxlX2FjdGlvbnNfYWRkZHVwMj15ZXMKZ2xf Y3ZfaGF2ZV9yYXdfZGVjbF9wb3NpeF9zcGF3bl9maWxlX2FjdGlvbnNfYWRkb3Bl bj15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9wb3NpeF9zcGF3bl9maWxlX2FjdGlv bnNfZGVzdHJveT15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9wb3NpeF9zcGF3bl9m aWxlX2FjdGlvbnNfaW5pdD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9wb3NpeF9z cGF3bmF0dHJfZGVzdHJveT15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9wb3NpeF9z cGF3bmF0dHJfZ2V0ZmxhZ3M9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfcG9zaXhf c3Bhd25hdHRyX2dldHBncm91cD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9wb3Np eF9zcGF3bmF0dHJfZ2V0c2NoZWRwYXJhbT15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVj bF9wb3NpeF9zcGF3bmF0dHJfZ2V0c2NoZWRwb2xpY3k9eWVzCmdsX2N2X2hhdmVf cmF3X2RlY2xfcG9zaXhfc3Bhd25hdHRyX2dldHNpZ2RlZmF1bHQ9eWVzCmdsX2N2 X2hhdmVfcmF3X2RlY2xfcG9zaXhfc3Bhd25hdHRyX2dldHNpZ21hc2s9eWVzCmds X2N2X2hhdmVfcmF3X2RlY2xfcG9zaXhfc3Bhd25hdHRyX2luaXQ9eWVzCmdsX2N2 X2hhdmVfcmF3X2RlY2xfcG9zaXhfc3Bhd25hdHRyX3NldGZsYWdzPXllcwpnbF9j dl9oYXZlX3Jhd19kZWNsX3Bvc2l4X3NwYXduYXR0cl9zZXRwZ3JvdXA9eWVzCmds X2N2X2hhdmVfcmF3X2RlY2xfcG9zaXhfc3Bhd25hdHRyX3NldHNjaGVkcGFyYW09 eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfcG9zaXhfc3Bhd25hdHRyX3NldHNjaGVk cG9saWN5PXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3Bvc2l4X3NwYXduYXR0cl9z ZXRzaWdkZWZhdWx0PXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3Bvc2l4X3NwYXdu YXR0cl9zZXRzaWdtYXNrPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3Bvc2l4X3Nw YXducD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9wcmVhZD15ZXMKZ2xfY3ZfaGF2 ZV9yYXdfZGVjbF9wc2VsZWN0PXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3B0aHJl YWRfc2lnbWFzaz15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9wdHNuYW1lPXllcwpn bF9jdl9oYXZlX3Jhd19kZWNsX3B3cml0ZT15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVj bF9yYW5kb209eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfcmF3bWVtY2hyPXllcwpn bF9jdl9oYXZlX3Jhd19kZWNsX3JlYWRkaXI9eWVzCmdsX2N2X2hhdmVfcmF3X2Rl Y2xfcmVhZGxpbms9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfcmVhZGxpbmthdD15 ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9yZWFscGF0aD15ZXMKZ2xfY3ZfaGF2ZV9y YXdfZGVjbF9yZW5hbWVhdD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9yZXdpbmRk aXI9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfcm1kaXI9eWVzCmdsX2N2X2hhdmVf cmF3X2RlY2xfcnBtYXRjaD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9zY2FuZGly PXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3NlbGVjdD15ZXMKZ2xfY3ZfaGF2ZV9y YXdfZGVjbF9zZXRlbnY9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfc2V0aG9zdG5h bWU9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfc2V0bG9jYWxlPXllcwpnbF9jdl9o YXZlX3Jhd19kZWNsX3NldHN0YXRlPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3Nl dHVzZXJzaGVsbD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9zaWdhY3Rpb249eWVz CmdsX2N2X2hhdmVfcmF3X2RlY2xfc2lnYWRkc2V0PXllcwpnbF9jdl9oYXZlX3Jh d19kZWNsX3NpZ2RlbHNldD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9zaWdlbXB0 eXNldD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9zaWdmaWxsc2V0PXllcwpnbF9j dl9oYXZlX3Jhd19kZWNsX3NpZ2lzbWVtYmVyPXllcwpnbF9jdl9oYXZlX3Jhd19k ZWNsX3NpZ3BlbmRpbmc9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfc2lncHJvY21h c2s9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfc2xlZXA9eWVzCmdsX2N2X2hhdmVf cmF3X2RlY2xfc25wcmludGY9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfc3JhbmRv bT15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9zdGF0PXllcwpnbF9jdl9oYXZlX3Jh d19kZWNsX3N0cGNweT15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9zdHBuY3B5PXll cwpnbF9jdl9oYXZlX3Jhd19kZWNsX3N0cmNhc2VzdHI9eWVzCmdsX2N2X2hhdmVf cmF3X2RlY2xfc3RyZHVwPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3N0cmVycm9y X3I9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfc3RybmNhdD15ZXMKZ2xfY3ZfaGF2 ZV9yYXdfZGVjbF9zdHJuZHVwPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3N0cm5s ZW49eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfc3RycGJyaz15ZXMKZ2xfY3ZfaGF2 ZV9yYXdfZGVjbF9zdHJzZXA9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfc3Ryc2ln bmFsPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3N0cnRvZD15ZXMKZ2xfY3ZfaGF2 ZV9yYXdfZGVjbF9zdHJ0b2ltYXg9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfc3Ry dG9rX3I9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfc3RydG9sbD15ZXMKZ2xfY3Zf aGF2ZV9yYXdfZGVjbF9zdHJ0b3VsbD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF9z dHJ0b3VtYXg9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfc3RydmVyc2NtcD1ubwpn bF9jdl9oYXZlX3Jhd19kZWNsX3N5bWxpbms9eWVzCmdsX2N2X2hhdmVfcmF3X2Rl Y2xfc3ltbGlua2F0PXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3RtcGZpbGU9eWVz CmdsX2N2X2hhdmVfcmF3X2RlY2xfdG93Y3RyYW5zPXllcwpnbF9jdl9oYXZlX3Jh d19kZWNsX3R0eW5hbWVfcj15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF91bmxpbms9 eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfdW5saW5rYXQ9eWVzCmdsX2N2X2hhdmVf cmF3X2RlY2xfdW5sb2NrcHQ9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfdW5zZXRl bnY9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfdXNsZWVwPXllcwpnbF9jdl9oYXZl X3Jhd19kZWNsX3ZkcHJpbnRmPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3ZzbnBy aW50Zj15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF93YWl0cGlkPXllcwpnbF9jdl9o YXZlX3Jhd19kZWNsX3djcGNweT15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF93Y3Bu Y3B5PXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3djcnRvbWI9eWVzCmdsX2N2X2hh dmVfcmF3X2RlY2xfd2NzY2FzZWNtcD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF93 Y3NjYXQ9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfd2NzY2hyPXllcwpnbF9jdl9o YXZlX3Jhd19kZWNsX3djc2NtcD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF93Y3Nj b2xsPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3djc2NweT15ZXMKZ2xfY3ZfaGF2 ZV9yYXdfZGVjbF93Y3Njc3BuPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3djc2R1 cD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF93Y3NsZW49eWVzCmdsX2N2X2hhdmVf cmF3X2RlY2xfd2NzbmNhc2VjbXA9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfd2Nz bmNhdD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF93Y3NuY21wPXllcwpnbF9jdl9o YXZlX3Jhd19kZWNsX3djc25jcHk9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfd2Nz bmxlbj15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF93Y3NucnRvbWJzPXllcwpnbF9j dl9oYXZlX3Jhd19kZWNsX3djc3Bicms9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xf d2NzcmNocj15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF93Y3NydG9tYnM9eWVzCmds X2N2X2hhdmVfcmF3X2RlY2xfd2Nzc3BuPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNs X3djc3N0cj15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF93Y3N0b2s9eWVzCmdsX2N2 X2hhdmVfcmF3X2RlY2xfd2Nzd2lkdGg9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xf d2NzeGZybT15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF93Y3RvYj15ZXMKZ2xfY3Zf aGF2ZV9yYXdfZGVjbF93Y3RyYW5zPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3dj dHlwZT15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF93Y3dpZHRoPXllcwpnbF9jdl9o YXZlX3Jhd19kZWNsX3dtZW1jaHI9eWVzCmdsX2N2X2hhdmVfcmF3X2RlY2xfd21l bWNtcD15ZXMKZ2xfY3ZfaGF2ZV9yYXdfZGVjbF93bWVtY3B5PXllcwpnbF9jdl9o YXZlX3Jhd19kZWNsX3dtZW1tb3ZlPXllcwpnbF9jdl9oYXZlX3Jhd19kZWNsX3dt ZW1zZXQ9eWVzCmdsX2N2X2hlYWRlcl9lcnJub19oX2NvbXBsZXRlPXllcwpnbF9j dl9oZWFkZXJfaW50dHlwZXNfaD15ZXMKZ2xfY3ZfaGVhZGVyX2xhbmdpbmZvX2Nv ZGVzZXQ9eWVzCmdsX2N2X2hlYWRlcl9sYW5naW5mb19lcmE9eWVzCmdsX2N2X2hl YWRlcl9sYW5naW5mb190X2ZtdF9hbXBtPXllcwpnbF9jdl9oZWFkZXJfbGFuZ2lu Zm9feWVzZXhwcj15ZXMKZ2xfY3ZfaGVhZGVyX2xvY2FsZV9oX3Bvc2l4MjAwMT15 ZXMKZ2xfY3ZfaGVhZGVyX3NpZ25hbF9oX1NJR1BJUEU9eWVzCmdsX2N2X2hlYWRl cl9zdGRpbnRfaD15ZXMKZ2xfY3ZfaGVhZGVyX3N5c19zZWxlY3RfaF9zZWxmY29u dGFpbmVkPXllcwpnbF9jdl9oZWFkZXJfd2NoYXJfaF9jb3JyZWN0X2lubGluZT15 ZXMKZ2xfY3Zfc2lnYWx0c3RhY2tfbG93X2Jhc2U9eWVzCmdsX2N2X3NpemVfbWF4 PXllcwpnbF9jdl9zeXNfc3RydWN0X3RpbWVzcGVjX2luX3RpbWVfaD15ZXMKZ2xf Y3Zfc3lzX3N0cnVjdF90aW1ldmFsPXllcwpnbF9jdl90eXBlX3NpZ3NldF90PXll cwpnbF9jdl90eXBlX3djaGFyX3Rfc2lnbmVkPXllcwpnbF9jdl90eXBlX3djdHJh bnNfdD15ZXMKZ2xfY3ZfdHlwZV93Y3R5cGVfdD15ZXMKZ2xfY3ZfdHlwZV93aW50 X3Rfc2lnbmVkPXllcwpnbF9jdl92YXJfc3RkaW5fbGFyZ2Vfb2Zmc2V0PXllcwpn dF9jdl9jX2ludG1heF90PXllcwpndF9jdl9jX3djaGFyX3Q9eWVzCmd0X2N2X2Nf d2ludF90PXllcwpndF9jdl9mdW5jX3ByaW50Zl9wb3NpeD15ZXMKZ3RfY3ZfZnVu Y191bnNldGVudl9yZXQ9aW50Cmd0X2N2X2ludF9kaXZieXplcm9fc2lnZnBlPXll cwpndF9jdl9zaWdpbmZvX3Q9eWVzCmd0X2N2X3NzaXplX3Q9eWVzCmx0X2N2X3Bh dGhfTUFHSUNfQ01EPS91c3IvYmluL2ZpbGUKbHRfY3Zfc3lzX21heF9jbWRfbGVu PTI2MjE0NAoKIyMgLS0tLS0tLS0tLS0tLS0tLS0gIyMKIyMgT3V0cHV0IHZhcmlh Ymxlcy4gIyMKIyMgLS0tLS0tLS0tLS0tLS0tLS0gIyMKCkFDTE9DQUw9JyR7U0hF TEx9IC92YXIvdG1wL3BvcnRzLWJ1aWxkL3Vzci9wb3J0cy9wb3J0cy1tZ210L3Br Zy93b3JrL3BrZy0xLjYuMi9taXNzaW5nIGFjbG9jYWwtMS4xNScKQU1ERVBCQUNL U0xBU0g9J1wnCkFNREVQX0ZBTFNFPScjJwpBTURFUF9UUlVFPScnCkFNVEFSPSck JHtUQVItdGFyfScKQU1fQkFDS1NMQVNIPSdcJwpBTV9ERUZBVUxUX1Y9JyQoQU1f REVGQVVMVF9WRVJCT1NJVFkpJwpBTV9ERUZBVUxUX1ZFUkJPU0lUWT0nMCcKQU1f Vj0nJChWKScKQVI9JycKQVVUT0NPTkY9JyR7U0hFTEx9IC92YXIvdG1wL3BvcnRz LWJ1aWxkL3Vzci9wb3J0cy9wb3J0cy1tZ210L3BrZy93b3JrL3BrZy0xLjYuMi9t aXNzaW5nIGF1dG9jb25mJwpBVVRPSEVBREVSPScke1NIRUxMfSAvdmFyL3RtcC9w b3J0cy1idWlsZC91c3IvcG9ydHMvcG9ydHMtbWdtdC9wa2cvd29yay9wa2ctMS42 LjIvbWlzc2luZyBhdXRvaGVhZGVyJwpBVVRPTUFLRT0nJHtTSEVMTH0gL3Zhci90 bXAvcG9ydHMtYnVpbGQvdXNyL3BvcnRzL3BvcnRzLW1nbXQvcGtnL3dvcmsvcGtn LTEuNi4yL21pc3NpbmcgYXV0b21ha2UtMS4xNScKQVdLPScvdXNyL2Jpbi9hd2sn CkJVSUxEX1NUQVRJQ19GQUxTRT0nJwpCVUlMRF9TVEFUSUNfVFJVRT0nJwpDQz0n Y2MnCkNDREVQTU9ERT0nJwpDRkxBR1M9Jy1PIC1waXBlICAtV25vLWVycm9yIC1m bm8tc3RyaWN0LWFsaWFzaW5nJwpDUFA9J2NwcCcKQ1BQRkxBR1M9JycKQ1lHUEFU SF9XPSdlY2hvJwpERUZTPScnCkRFUERJUj0nLmRlcHMnCkRMTFRPT0w9JycKRFNZ TVVUSUw9JycKRFVNUEJJTj0nJwpEWU5BTUlDX0ZBTFNFPScnCkRZTkFNSUNfVFJV RT0nJwpFQ0hPX0M9JycKRUNIT19OPSctbicKRUNIT19UPScnCkVHUkVQPScnCkVY RUVYVD0nJwpGR1JFUD0nJwpGSUxFTUFQPScnCkdJVEJJTj0nJwpHSVRfSEVBRD0n JwpHUkVQPScnCkhBVkVfRUxGX0FCSV9GQUxTRT0nJwpIQVZFX0VMRl9BQklfVFJV RT0nJwpIQVZFX0xETlM9JycKSEFWRV9MRF9WRVJTSU9OX1NDUklQVF9GQUxTRT0n JwpIQVZFX0xEX1ZFUlNJT05fU0NSSVBUX1RSVUU9JycKSEFWRV9NQUNIT19BQklf RkFMU0U9JycKSEFWRV9NQUNIT19BQklfVFJVRT0nJwpIQVZFX1NFUVBBQ0tFVD0n JwpJTlNUQUxMX0RBVEE9J2luc3RhbGwgIC1tIDA2NDQnCklOU1RBTExfUFJPR1JB TT0naW5zdGFsbCAgLXMgLW0gNTU1JwpJTlNUQUxMX1NDUklQVD0naW5zdGFsbCAg LW0gNTU1JwpJTlNUQUxMX1NUUklQX1BST0dSQU09JyQoaW5zdGFsbF9zaCkgLWMg LXMnCkxEPScnCkxERkxBR1M9JycKTEROU19DRkxBR1M9JycKTEROU19MSUJTPScn CkxJQkJTRF9MSUI9JycKTElCRUxGX0JVTkRMRURfRkFMU0U9JycKTElCRUxGX0JV TkRMRURfVFJVRT0nJwpMSUJKQUlMX0xJQj0nJwpMSUJPQkpTPScnCkxJQlBLR19T T19WRVJTSU9OPSczOjA6MCcKTElCUz0nJwpMSUJUT09MPScnCkxJUE89JycKTE5f Uz0nJwpMVExJQk9CSlM9JycKTFRfU1lTX0xJQlJBUllfUEFUSD0nJwpNQUlOVD0n IycKTUFJTlRBSU5FUl9NT0RFX0ZBTFNFPScnCk1BSU5UQUlORVJfTU9ERV9UUlVF PScjJwpNQUtFSU5GTz0nJHtTSEVMTH0gL3Zhci90bXAvcG9ydHMtYnVpbGQvdXNy L3BvcnRzL3BvcnRzLW1nbXQvcGtnL3dvcmsvcGtnLTEuNi4yL21pc3NpbmcgbWFr ZWluZm8nCk1BTklGRVNUX1RPT0w9JycKTUtESVJfUD0nL2Jpbi9ta2RpciAtcCcK Tk09JycKTk1FRElUPScnCk9CSkRVTVA9JycKT0JKRVhUPScnCk9TX0NGTEFHUz0n JwpPU19MREZMQUdTPScnCk9TX0xJQlM9JycKT1NfU1RBVElDPScnCk9UT09MNjQ9 JycKT1RPT0w9JycKUEFDS0FHRT0ncGtnJwpQQUNLQUdFX0JVR1JFUE9SVD0naHR0 cHM6Ly9naXRodWIuY29tL2ZyZWVic2QvcGtnJwpQQUNLQUdFX05BTUU9J3BrZycK UEFDS0FHRV9TVFJJTkc9J3BrZyAxLjYuMicKUEFDS0FHRV9UQVJOQU1FPSdwa2cn ClBBQ0tBR0VfVVJMPScnClBBQ0tBR0VfVkVSU0lPTj0nMS42LjInClBBVEhfU0VQ QVJBVE9SPSc6JwpQS0dfQ09ORklHPScnClBLR19DT05GSUdfTElCRElSPScnClBL R19DT05GSUdfUEFUSD0nJwpSQU5MSUI9JycKUkVQT1M9JycKUkVQT1NfTERBREQ9 JycKUkVQT1NfTERBRERfU1RBVElDPScnClNFRD0nJwpTRVRfTUFLRT0nJwpTSEVM TD0nL2Jpbi9zaCcKU1RSSVA9JycKVEVTVFM9JycKVkVSU0lPTj0nMS42LjInCmFj X2N0X0FSPScnCmFjX2N0X0NDPSdjYycKYWNfY3RfRFVNUEJJTj0nJwphbV9fRVhF RVhUX0ZBTFNFPScnCmFtX19FWEVFWFRfVFJVRT0nJwphbV9fZmFzdGRlcENDX0ZB TFNFPScnCmFtX19mYXN0ZGVwQ0NfVFJVRT0nJwphbV9faW5jbHVkZT0naW5jbHVk ZScKYW1fX2lzcmM9JycKYW1fX2xlYWRpbmdfZG90PScuJwphbV9fbm9kZXA9J19u bycKYW1fX3F1b3RlPScnCmFtX190YXI9JyQke1RBUi10YXJ9IGNob2YgLSAiJCR0 YXJkaXIiJwphbV9fdW50YXI9JyQke1RBUi10YXJ9IHhmIC0nCmJpbmRpcj0nJHtl eGVjX3ByZWZpeH0vYmluJwpidWlsZD0nYXJtLXBvcnRibGQtZnJlZWJzZDExLjAn CmJ1aWxkX2FsaWFzPSdhcm0tcG9ydGJsZC1mcmVlYnNkMTEuMCcKYnVpbGRfY3B1 PScnCmJ1aWxkX29zPScnCmJ1aWxkX3ZlbmRvcj0nJwpkYXRhZGlyPScke2RhdGFy b290ZGlyfScKZGF0YXJvb3RkaXI9JyR7cHJlZml4fS9zaGFyZScKZG9jZGlyPSck e2RhdGFyb290ZGlyfS9kb2MvJHtQQUNLQUdFX1RBUk5BTUV9JwpkdmlkaXI9JyR7 ZG9jZGlyfScKZXhlY19wcmVmaXg9J05PTkUnCmhvc3Q9JycKaG9zdF9hbGlhcz0n Jwpob3N0X2NwdT0nJwpob3N0X29zPScnCmhvc3RfdmVuZG9yPScnCmh0bWxkaXI9 JyR7ZG9jZGlyfScKaW5jbHVkZWRpcj0nJHtwcmVmaXh9L2luY2x1ZGUnCmluZm9k aXI9Jy91c3IvbG9jYWwvaW5mbycKaW5zdGFsbF9zaD0nJHtTSEVMTH0gL3Zhci90 bXAvcG9ydHMtYnVpbGQvdXNyL3BvcnRzL3BvcnRzLW1nbXQvcGtnL3dvcmsvcGtn LTEuNi4yL2luc3RhbGwtc2gnCmxpYmRpcj0nJHtleGVjX3ByZWZpeH0vbGliJwps aWJleGVjZGlyPScke2V4ZWNfcHJlZml4fS9saWJleGVjJwpsb2NhbGVkaXI9JyR7 ZGF0YXJvb3RkaXJ9L2xvY2FsZScKbG9jYWxzdGF0ZWRpcj0nL3ZhcicKbWFuZGly PScvdXNyL2xvY2FsL21hbicKbWtkaXJfcD0nJChNS0RJUl9QKScKb2xkaW5jbHVk ZWRpcj0nL3Vzci9pbmNsdWRlJwpwZGZkaXI9JyR7ZG9jZGlyfScKcHJlZml4PScv dXNyL2xvY2FsJwpwcm9ncmFtX3RyYW5zZm9ybV9uYW1lPSdzLHgseCwnCnBzZGly PScke2RvY2Rpcn0nCnNiaW5kaXI9JyR7ZXhlY19wcmVmaXh9L3NiaW4nCnNoYXJl ZHN0YXRlZGlyPScke3ByZWZpeH0vY29tJwpzeXNjb25mZGlyPScke3ByZWZpeH0v ZXRjJwp0YXJnZXRfYWxpYXM9JycKCiMjIC0tLS0tLS0tLS0tICMjCiMjIGNvbmZk ZWZzLmguICMjCiMjIC0tLS0tLS0tLS0tICMjCgovKiBjb25mZGVmcy5oICovCiNk ZWZpbmUgUEFDS0FHRV9OQU1FICJwa2ciCiNkZWZpbmUgUEFDS0FHRV9UQVJOQU1F ICJwa2ciCiNkZWZpbmUgUEFDS0FHRV9WRVJTSU9OICIxLjYuMiIKI2RlZmluZSBQ QUNLQUdFX1NUUklORyAicGtnIDEuNi4yIgojZGVmaW5lIFBBQ0tBR0VfQlVHUkVQ T1JUICJodHRwczovL2dpdGh1Yi5jb20vZnJlZWJzZC9wa2ciCiNkZWZpbmUgUEFD S0FHRV9VUkwgIiIKI2RlZmluZSBQQUNLQUdFICJwa2ciCiNkZWZpbmUgVkVSU0lP TiAiMS42LjIiCgpjb25maWd1cmU6IGV4aXQgNzcK ------------7Q8RxOqXNDXZskN6CFMV3p-- From owner-freebsd-arm@freebsd.org Wed Dec 23 22:21:58 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5913A4F11C for ; Wed, 23 Dec 2015 22:21:58 +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 8ACB41316 for ; Wed, 23 Dec 2015 22:21:58 +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; Wed, 23 Dec 2015 22:22:14 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBNMLtPv004272; Wed, 23 Dec 2015 15:21:55 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1450909315.25138.215.camel@freebsd.org> Subject: Re: ports-mgmt/pkg does not build From: Ian Lepore To: Ronald Klop , freebsd-arm@freebsd.org Date: Wed, 23 Dec 2015 15:21:55 -0700 In-Reply-To: References: 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: Wed, 23 Dec 2015 22:21:58 -0000 On Wed, 2015-12-23 at 23:01 +0100, Ronald Klop wrote: > Hello, > > I upgraded my Sheevaplug from CURRENT r285336 (Jul 10) to r292343 > (Dec > 16). This went from clang 3.6.1 to 3.7.0. > This runs, but building potrs-mgmt/pkg does not work. > The error of clang is: > error: no handler registered for module format 'raw' > fatal error: error in backend: unknown module format > > See http://www.klop.ws/config.log for more information. > > What could be the cause of this? Or what information can I provide to > help? > > Regards, > Ronald. This isn't a problem with ports, it's a problem with clang 3.7 -- it just doesn't work on armv4/5. It works to crossbuild from amd64, but when run native on arm it fails. It's a known problem that nobody is working on, because the old arm stuff just doesn't get any love anymore. When I needed to do a bit of testing on dreamplug recently I just switched to the old gcc compiler. -- Ian From owner-freebsd-arm@freebsd.org Thu Dec 24 06:39: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 20414A50041 for ; Thu, 24 Dec 2015 06:39:11 +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 E9AD01DA1 for ; Thu, 24 Dec 2015 06:39:10 +0000 (UTC) (envelope-from tim@kientzle.com) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id tBO6Jx6J081303; Thu, 24 Dec 2015 06:19:59 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 5t9t8wkvu9ygu2h57nbyaafx3a; Thu, 24 Dec 2015 06:19:59 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Booting the ELF kernel without ubldr on Raspberry Pi From: Tim Kientzle In-Reply-To: Date: Wed, 23 Dec 2015 22:18:44 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <32849B9F-C7B8-4A86-B8F1-043F62D2E64C@kientzle.com> References: To: Sylvain Garrigues 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, 24 Dec 2015 06:39:11 -0000 Actually, it would be more interesting to go a step further and boot the = FreeBSD kernel directly from the firmware, bypassing both U-Boot and = ubldr. Warner did some work long ago to allow the FreeBSD kernel to boot from a = Linux boot loader, which should make this possible. You might try = looking at that code and seeing if you can get it to work. Cheers, Tim > On Dec 21, 2015, at 7:48 PM, Sylvain Garrigues = wrote: >=20 > Hello, >=20 > I=E2=80=99d like to boot FreeBSD directly with u-boot, without ubldr, = using an image provided by the u-boot mkimage tool. The reason is = simple: mkimage can deal with compressed kernels and will therefore = speed my boot time. And I want to try it anyway, as it seems possible = reading = http://bsdcan.org/2008/schedule/attachments/49_2008_uboot_freebsd.pdf = = and various other=20 >=20 > Before going there and using an mkimage, I=E2=80=99d like to boot the = kernel image just with the same bootelf version provided by the = sysutils/u-boot-rpi2 port. It doesn=E2=80=99t display anything and = crashes (I think I can see =C2=AB illegal instruction =C2=BB just before = the board reboots). I don=E2=80=99t understand why, and this is my first = question. >=20 > Then I looked at the mkimage utility, although we can specify and = freebsd kernel type through the -O flag, the bootm command only = understands linux and NetBSD. I guess I should use linux there? >=20 > Thanks for your help, > Sylvain >=20 >=20 > PS: FYI, below is: >=20 > 1/ info about my kernel (I can see the entry point is at 0xc0100100), = copied into the fat partition >=20 > # readelf -h = /root/crochet/work/obj/arm.armv6/root/crochet/src/sys/RPI2/kernel = =20 > ELF Header: > Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00=20 > Class: ELF32 > Data: 2's complement, little endian > Version: 1 (current) > OS/ABI: UNIX - System V > ABI Version: 0 > Type: EXEC (Executable file) > Machine: ARM > Version: 0x1 > Entry point address: 0xc0100100 > Start of program headers: 52 (bytes into file) > Start of section headers: 6235080 (bytes into file) > Flags: 0x5000202, has entry point, = Version5 EABI, > Size of this header: 52 (bytes) > Size of program headers: 32 (bytes) > Number of program headers: 6 > Size of section headers: 40 (bytes) > Number of section headers: 38 > Section header string table index: 35 > [root@clad /usr/ports/sysutils/u-boot-rpi2]# =20 >=20 > 2/ the interesting part of my include/configs/rpi-common.h from = u-boot: >=20 > #define CONFIG_EXTRA_ENV_SETTINGS \ > ENV_DEVICE_SETTINGS \ > "loadaddr=3D0x02000000\0" \ > "Fatboot=3D" \ > "env exists loaderdev || env set loaderdev ${fatdev}; " \ > "echo Booting from: ${fatdev} ${bootfile}; " \ > "fatload ${fatdev} ${loadaddr} ${bootfile} && bootelf = ${loadaddr}; " \ > "\0" \ > "preboot=3D" \ > "fdt addr 0x100; " \ > "env set bootfile kernel; " \ =20 > "env set fatdev 'mmc 0'; " \ > "\0" > #undef CONFIG_BOOTCOMMAND > #define CONFIG_BOOTCOMMAND "run Fatboot" > #undef CONFIG_PREBOOT > #define CONFIG_PREBOOT "run preboot" > _______________________________________________ > 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 Thu Dec 24 10: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 063ADA5101C for ; Thu, 24 Dec 2015 10:51:12 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E26C1731 for ; Thu, 24 Dec 2015 10:51:11 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wm0-x22e.google.com with SMTP id l126so178177992wml.0 for ; Thu, 24 Dec 2015 02:51:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=M/uWTZOyQM8lge6LME/4xfIXAveLOxCfOezKlQo4mXs=; b=ZEyzOklZCNI2MFhonhszFX7De3e4PDL9cyv6zJA7tWMEEXf1nwDWSpFYMrdrGhGkB8 d3Ybdk9dLd4q5f8zg+NJ/uZ3D5kQ1kQG1Y+Nkd+87Y6Dk182ROSa4baOQX4if/eR6FpO kOQFtvdSjEplIvpe08yRaKoPhZqNo4fsqsf3yRKYBiXt1E0pCsCNlADjkkqIp29fmfJu xQQtKxKFPv6zgMBXSg5qM8hE9KCL0F3MkKpcJ8VWjqR2laHl/atHsN8ljp8zcbvxDAh0 Oq626yJfHyjPNGiDX9h6S7qm1n8ZdrGv88KEah/V1FdnnebrQoAqifmFxE4AneDjvpA2 Kv/g== X-Received: by 10.28.13.138 with SMTP id 132mr41997702wmn.62.1450954269746; Thu, 24 Dec 2015 02:51:09 -0800 (PST) Received: from [192.168.0.5] (lns-bzn-50f-81-56-235-196.adsl.proxad.net. [81.56.235.196]) by smtp.gmail.com with ESMTPSA id m70sm30654253wmb.0.2015.12.24.02.51.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Dec 2015 02:51:08 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Booting the ELF kernel without ubldr on Raspberry Pi From: Sylvain Garrigues In-Reply-To: <32849B9F-C7B8-4A86-B8F1-043F62D2E64C@kientzle.com> Date: Thu, 24 Dec 2015 11:51:07 +0100 Cc: freebsd-arm Message-Id: <8F62699C-126D-492D-8B7E-8C250ED5BC07@gmail.com> References: <32849B9F-C7B8-4A86-B8F1-043F62D2E64C@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.3112) 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: Thu, 24 Dec 2015 10:51:12 -0000 If I look at what gonzo did for VERSATILEPB, I think it can be done = easily by writing a tiny assembly code that does something like what he = did: # set r0..r3 to zero /usr/bin/printf "\0\0\240\343" > ${WORKDIR}/first_commands /usr/bin/printf "\0\020\240\343" >> ${WORKDIR}/first_commands /usr/bin/printf "\0\040\240\343" >> ${WORKDIR}/first_commands /usr/bin/printf "\0\060\240\343" >> ${WORKDIR}/first_commands =20 # jump to kernel entry point /usr/bin/printf "\001\366\240\343" >> ${WORKDIR}/first_commands =20 # install kernel [ ! -d ${WORKDIR}/_.kernel.bin ] && mkdir ${WORKDIR}/_.kernel.bin board_default_installkernel ${WORKDIR}/_.kernel.bin dd of=3D$VERSATILEPB_FLASH bs=3D1M count=3D4 if=3D/dev/zero dd of=3D$VERSATILEPB_FLASH bs=3D1 conv=3Dnotrunc = if=3D${WORKDIR}/first_commands dd of=3D$VERSATILEPB_FLASH bs=3D64k oseek=3D15 conv=3Dnotrunc = if=3D${WORKDIR}/_.kernel.bin/boot/kernel/kernel.bin The only problem for the Raspberry pi is that, if I am correct, the DTB = is modified by the firmware (bootcode.bin) so I can=E2=80=99t statically = compile the DTB in the kernel like for VERSATILEPB :( I would need to = mimic what loader does and create a kernel environment variable which = contains the address to the DTB. This is a good exercice, but it doesn=E2=80=99t solve my project which = is to: 1/ have a self-extracting kernel or have a loader which uncompress the = kernel, so that it takes much less time to start (my benchmark is = raspbian or openelec).=20 =3D=3D> I compiled ubldr with LOADER_GZIP_SUPPORT and compressed kernel = to kernel.gz, reducing the size by 2. The loader does manage to load, = uncompress and boot the kernel.gz, but the loading time is worse than = when uncompressed, so I=E2=80=99m stuck I don=E2=80=99t know what=E2=80=99= s wrong? 2/ have the bootloader / kernel display a nice splash screen while the = kernel boots =3D=3D> for that I looked at u-boot splash screen but the quality of the = rendering is too poor (8-bit bitmap). I looked at the VT frame buffer = but the slash screen feature is also limited. So I might now look into = the misc/raspberrypi-userland port and understand how the hello_jpeg = sample code does that with the GPU, then I plan to port it in the kernel = initialization code, not sure it=E2=80=99s going to work)=20 Have a good day > Le 24 d=C3=A9c. 2015 =C3=A0 07:18, Tim Kientzle a = =C3=A9crit : >=20 > Actually, it would be more interesting to go a step further and boot = the FreeBSD kernel directly from the firmware, bypassing both U-Boot and = ubldr. >=20 > Warner did some work long ago to allow the FreeBSD kernel to boot from = a Linux boot loader, which should make this possible. You might try = looking at that code and seeing if you can get it to work. >=20 > Cheers, >=20 > Tim >=20 >=20 >> On Dec 21, 2015, at 7:48 PM, Sylvain Garrigues > wrote: >>=20 >> Hello, >>=20 >> I=E2=80=99d like to boot FreeBSD directly with u-boot, without ubldr, = using an image provided by the u-boot mkimage tool. The reason is = simple: mkimage can deal with compressed kernels and will therefore = speed my boot time. And I want to try it anyway, as it seems possible = reading = http://bsdcan.org/2008/schedule/attachments/49_2008_uboot_freebsd.pdf = > = and various other=20 >>=20 >> Before going there and using an mkimage, I=E2=80=99d like to boot the = kernel image just with the same bootelf version provided by the = sysutils/u-boot-rpi2 port. It doesn=E2=80=99t display anything and = crashes (I think I can see =C2=AB illegal instruction =C2=BB just before = the board reboots). I don=E2=80=99t understand why, and this is my first = question. >>=20 >> Then I looked at the mkimage utility, although we can specify and = freebsd kernel type through the -O flag, the bootm command only = understands linux and NetBSD. I guess I should use linux there? >>=20 >> Thanks for your help, >> Sylvain >>=20 >>=20 >> PS: FYI, below is: >>=20 >> 1/ info about my kernel (I can see the entry point is at 0xc0100100), = copied into the fat partition >>=20 >> # readelf -h = /root/crochet/work/obj/arm.armv6/root/crochet/src/sys/RPI2/kernel = =20 >> ELF Header: >> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00=20 >> Class: ELF32 >> Data: 2's complement, little endian >> Version: 1 (current) >> OS/ABI: UNIX - System V >> ABI Version: 0 >> Type: EXEC (Executable file) >> Machine: ARM >> Version: 0x1 >> Entry point address: 0xc0100100 >> Start of program headers: 52 (bytes into file) >> Start of section headers: 6235080 (bytes into file) >> Flags: 0x5000202, has entry point, = Version5 EABI, >> Size of this header: 52 (bytes) >> Size of program headers: 32 (bytes) >> Number of program headers: 6 >> Size of section headers: 40 (bytes) >> Number of section headers: 38 >> Section header string table index: 35 >> [root@clad /usr/ports/sysutils/u-boot-rpi2]# =20 >>=20 >> 2/ the interesting part of my include/configs/rpi-common.h from = u-boot: >>=20 >> #define CONFIG_EXTRA_ENV_SETTINGS \ >> ENV_DEVICE_SETTINGS \ >> "loadaddr=3D0x02000000\0" \ >> "Fatboot=3D" \ >> "env exists loaderdev || env set loaderdev ${fatdev}; " \ >> "echo Booting from: ${fatdev} ${bootfile}; " \ >> "fatload ${fatdev} ${loadaddr} ${bootfile} && bootelf = ${loadaddr}; " \ >> "\0" \ >> "preboot=3D" \ >> "fdt addr 0x100; " \ >> "env set bootfile kernel; " \ =20 >> "env set fatdev 'mmc 0'; " \ >> "\0" >> #undef CONFIG_BOOTCOMMAND >> #define CONFIG_BOOTCOMMAND "run Fatboot" >> #undef CONFIG_PREBOOT >> #define CONFIG_PREBOOT "run preboot" >> _______________________________________________ >> 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 Thu Dec 24 14:34:22 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 C4417A51CE7 for ; Thu, 24 Dec 2015 14:34:22 +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 8342B1D41 for ; Thu, 24 Dec 2015 14:34:22 +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 1aC6y6-000Eep-Si for freebsd-arm@freebsd.org; Thu, 24 Dec 2015 16:34:14 +0200 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: rpi wifi/wlan0 stopped working Message-Id: <2FD9A764-9F86-4DF1-B8F8-964678BFC21D@cs.huji.ac.il> Date: Thu, 24 Dec 2015 16:34:14 +0200 To: freebsd-arm@freebsd.org 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: Thu, 24 Dec 2015 14:34:22 -0000 with an older current, my rpi sees the wifi, and it actually works, with a more resent current, ifconfig does not show it. when I take out the dongle: root@:~ # ugen0.4: at usbus0 (disconnected) urtwn0: at uhub1, port 4, addr 4 (disconnected) when I re insert it: ugen0.4: at usbus0 urtwn0: on = usbus0 urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R but: root@:~ # ifconfig lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1=20 inet 127.0.0.1 netmask 0xff000000=20 groups: lo=20 nd6 options=3D21 ue0: flags=3D8843 metric 0 mtu = 1500 options=3D80001 ether b8:27:eb:8e:39:ef media: Ethernet autoselect (none) status: no carrier nd6 options=3D29 no wlan0, nada any idea what I=E2=80=99m missing? cheers, danny From owner-freebsd-arm@freebsd.org Thu Dec 24 14:47: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 9FE93A4F1BC for ; Thu, 24 Dec 2015 14:47:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72FDC12A2 for ; Thu, 24 Dec 2015 14:47:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x235.google.com with SMTP id o67so243858960iof.3 for ; Thu, 24 Dec 2015 06:47:21 -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=IKM7HqEKcd7fH4Twh1WDS9mVGPhbKQGfuzw/Bohyw5U=; b=ISfi3VdwGnmexul11B7HiZV/A/LE+huzNR/JpoBSTWw5hDpzha1rh7itPvJ3QMZgsN t8orX8tzccJeGnifraECGIpLOjscUH9yRPte9TaLo9qSnO2QTTf/Tw9wWilAdD3rNqZw +cMLoQrbWeZt09LjhpmJLCv5PemBzBMMcD8fyDlyhhxH996GcFP3qDzMynVNHjk0qDDg PPbXDCXKk+5u5UzxT9wJngGj2Rd8mu12re9wOLvwxZEflb99MQndJL0Ae+N/HD1DI2NQ PwqsDCbYm/TSNIRGTsCMYlTTK09tc9/07FctMFb34Ql8PMaSKap0hOEcAcOUT0U2D2Gy QlrA== MIME-Version: 1.0 X-Received: by 10.107.162.21 with SMTP id l21mr34664421ioe.123.1450968440791; Thu, 24 Dec 2015 06:47:20 -0800 (PST) Received: by 10.36.121.202 with HTTP; Thu, 24 Dec 2015 06:47:20 -0800 (PST) In-Reply-To: <2FD9A764-9F86-4DF1-B8F8-964678BFC21D@cs.huji.ac.il> References: <2FD9A764-9F86-4DF1-B8F8-964678BFC21D@cs.huji.ac.il> Date: Thu, 24 Dec 2015 06:47:20 -0800 Message-ID: Subject: Re: rpi wifi/wlan0 stopped working From: Adrian Chadd To: Daniel Braniss Cc: "freebsd-arm@freebsd.org" 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: Thu, 24 Dec 2015 14:47:21 -0000 try 'sysctl net.wlan.devices' ; see if urtwn0 shows up. Newer -head removed the need for the hardware interface in ifconfig, as it's not used. -a On 24 December 2015 at 06:34, Daniel Braniss wrote: > with an older current, my rpi sees the wifi, and it actually works, > with a more resent current, ifconfig does not show it. > > when I take out the dongle: > root@:~ # ugen0.4: at usbus0 (disconnected) > urtwn0: at uhub1, port 4, addr 4 (disconnected) > > when I re insert it: > > ugen0.4: at usbus0 > urtwn0: on usbus0 > urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R > > but: > > root@:~ # ifconfig > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > groups: lo > nd6 options=3D21 > ue0: flags=3D8843 metric 0 mtu 15= 00 > options=3D80001 > ether b8:27:eb:8e:39:ef > media: Ethernet autoselect (none) > status: no carrier > nd6 options=3D29 > > no wlan0, nada > > any idea what I=E2=80=99m missing? > > cheers, > danny > > _______________________________________________ > 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 Thu Dec 24 15:20: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 6A552A4FE12 for ; Thu, 24 Dec 2015 15:20:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (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 3F881150A for ; Thu, 24 Dec 2015 15:20:18 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 24 Dec 2015 15:19:48 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBOFKE8r005789; Thu, 24 Dec 2015 08:20:14 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1450970414.25138.238.camel@freebsd.org> Subject: Re: Booting the ELF kernel without ubldr on Raspberry Pi From: Ian Lepore To: Sylvain Garrigues , Tim Kientzle Cc: freebsd-arm Date: Thu, 24 Dec 2015 08:20:14 -0700 In-Reply-To: <8F62699C-126D-492D-8B7E-8C250ED5BC07@gmail.com> References: <32849B9F-C7B8-4A86-B8F1-043F62D2E64C@kientzle.com> <8F62699C-126D-492D-8B7E-8C250ED5BC07@gmail.com> Content-Type: text/plain; charset="iso-8859-13" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 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: Thu, 24 Dec 2015 15:20:19 -0000 On Thu, 2015-12-24 at 11:51 +0100, Sylvain Garrigues wrote: > If I look at what gonzo did for VERSATILEPB, I think it can be done > easily by writing a tiny assembly code that does something like what > he did: > > # set r0..r3 to zero > /usr/bin/printf "\0\0\240\343" > ${WORKDIR}/first_commands > /usr/bin/printf "\0\020\240\343" >> ${WORKDIR}/first_commands > /usr/bin/printf "\0\040\240\343" >> ${WORKDIR}/first_commands > /usr/bin/printf "\0\060\240\343" >> ${WORKDIR}/first_commands > > # jump to kernel entry point > /usr/bin/printf "\001\366\240\343" >> ${WORKDIR}/first_commands > > # install kernel > [ ! -d ${WORKDIR}/_.kernel.bin ] && mkdir ${WORKDIR}/_.kernel.bin > board_default_installkernel ${WORKDIR}/_.kernel.bin > > dd of=$VERSATILEPB_FLASH bs=1M count=4 if=/dev/zero > dd of=$VERSATILEPB_FLASH bs=1 conv=notrunc > if=${WORKDIR}/first_commands > dd of=$VERSATILEPB_FLASH bs=64k oseek=15 conv=notrunc > if=${WORKDIR}/_.kernel.bin/boot/kernel/kernel.bin > > The only problem for the Raspberry pi is that, if I am correct, the > DTB is modified by the firmware (bootcode.bin) so I canÿt statically > compile the DTB in the kernel like for VERSATILEPB :( I would need to > mimic what loader does and create a kernel environment variable which > contains the address to the DTB. > > This is a good exercice, but it doesnÿt solve my project which is to: > > 1/ have a self-extracting kernel or have a loader which uncompress > the kernel, so that it takes much less time to start (my benchmark is > raspbian or openelec). > ==> I compiled ubldr with LOADER_GZIP_SUPPORT and compressed kernel > to kernel.gz, reducing the size by 2. The loader does manage to load, > uncompress and boot the kernel.gz, but the loading time is worse than > when uncompressed, so Iÿm stuck I donÿt know whatÿs wrong? > > 2/ have the bootloader / kernel display a nice splash screen while > the kernel boots > ==> for that I looked at u-boot splash screen but the quality of the > rendering is too poor (8-bit bitmap). I looked at the VT frame buffer > but the slash screen feature is also limited. So I might now look > into the misc/raspberrypi-userland port and understand how the > hello_jpeg sample code does that with the GPU, then I plan to port it > in the kernel initialization code, not sure itÿs going to work) What version of u-boot are you using for this? I don't understand the obsession with the time it takes to load the kernel unless something unusual is happening. On my systems the time it takes to load a kernel, whether it's u-boot or ubldr doing the work, is pretty much exactly the time it takes to read the media the kernel is on. On an sdcard that's usually a few seconds, on gigabit ethernet it tends to be far less than one second. But all of that assumes that caching is enabled in u-boot, and it wasn't in some of the older ports. When u-boot starts does it say anything about the caches being enabled or disabled? Is the dcache command available? If not, it's probably not enabled, and a newer u-boot may fix the problem. I hope to be updating all our u-boot ports over the next month or so. -- Ian From owner-freebsd-arm@freebsd.org Thu Dec 24 15:40: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 92270A50744 for ; Thu, 24 Dec 2015 15:40:19 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 3098010E7; Thu, 24 Dec 2015 15:40:19 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id l126so185340225wml.0; Thu, 24 Dec 2015 07:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tLYxRmnd9VXg+efs0pVJKUVQekfMRYminzCoTGphhsQ=; b=rl/C9kg3lqV2ZRGCa3Uu3UPOEiJAb1qm0vZKbtKqAqVe77wqBfShdbALyfDsYstznc U1yMwXpeukVEwIRbF/6CNfAsxOGwPho6307hPcO0Ak/dm052tlfISMyNGqY9IE9Edmk8 NhDS+ciGHhToZoW/M/mxnlVN8xgWvcDmhNR9tVbfsZgAODiBGlLb0CSSSp0s7boaiIeU yw+ayceagG4AARglGQOYvaR+T52rbqwXa95G46qN6/W8AbW8cIsNEoFh2Dke9/LQkrpB 7iQscuJ5d9Je3mWECFSggWtdprDPG1FLxS4mD6iFuiiJfdh70a4fVD9tHzmostpTbpoS n1ig== X-Received: by 10.194.243.227 with SMTP id xb3mr42718782wjc.96.1450971616528; Thu, 24 Dec 2015 07:40:16 -0800 (PST) Received: from [192.168.0.5] (lns-bzn-50f-81-56-235-196.adsl.proxad.net. [81.56.235.196]) by smtp.gmail.com with ESMTPSA id x125sm32687873wmg.1.2015.12.24.07.40.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Dec 2015 07:40:15 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Booting the ELF kernel without ubldr on Raspberry Pi From: Sylvain Garrigues In-Reply-To: <1450970414.25138.238.camel@freebsd.org> Date: Thu, 24 Dec 2015 16:40:13 +0100 Cc: Tim Kientzle , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <32849B9F-C7B8-4A86-B8F1-043F62D2E64C@kientzle.com> <8F62699C-126D-492D-8B7E-8C250ED5BC07@gmail.com> <1450970414.25138.238.camel@freebsd.org> To: Ian Lepore 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, 24 Dec 2015 15:40:19 -0000 Hello Ian, I=E2=80=99m using u-boot from the ports (sysutils/u-boot-rpi2). It = doesn=E2=80=99t display anything about cache being enabled. I was just comparing the time it takes to have the Linux kernel prints = its first lines, and the time it takes for the FreeBSD kernel to print = its own (the =C2=AB Copyright =C2=BB line) when used with u-boot+loader. For the former, it=E2=80=99s under a second, for the latter it=E2=80=99s = about 3-4 seconds (mainly spent when the loader loads the elf kernel). So I was wondered how they made it and was led to believe the Linux = kernel is compressed (and self-extracting), leading to less loading time = from the SD card which apparently is the bottleneck. So since the FreeBSD kernel has no =C2=AB self-extracting =C2=BB = feature, and since ubldr doesn=E2=80=99t seem to support the extracting = of a gzip kernel (well it seems to work with LOADER_GZIP_SUPPORT but I = see no gain), I was trying to use the compression and extraction feature = of u-boot with the use of recent mkimage with support for lzma = compression. I thought I could boot directly a LZMA compressed = kernel.bin with mkimage, without ubldr. But I forgot about the kernel = expecting a variable with the DTB address, which is set up by ubldr, so = I give up and will wait to see if someone is interested in implementing = a self-extracting kernel in the future. Best, Sylvain =20 > Le 24 d=C3=A9c. 2015 =C3=A0 16:20, Ian Lepore a = =C3=A9crit : >=20 > On Thu, 2015-12-24 at 11:51 +0100, Sylvain Garrigues wrote: >> If I look at what gonzo did for VERSATILEPB, I think it can be done >> easily by writing a tiny assembly code that does something like what >> he did: >>=20 >> # set r0..r3 to zero >> /usr/bin/printf "\0\0\240\343" > ${WORKDIR}/first_commands >> /usr/bin/printf "\0\020\240\343" >> ${WORKDIR}/first_commands >> /usr/bin/printf "\0\040\240\343" >> ${WORKDIR}/first_commands >> /usr/bin/printf "\0\060\240\343" >> ${WORKDIR}/first_commands >>=20 >> # jump to kernel entry point >> /usr/bin/printf "\001\366\240\343" >> ${WORKDIR}/first_commands >>=20 >> # install kernel >> [ ! -d ${WORKDIR}/_.kernel.bin ] && mkdir ${WORKDIR}/_.kernel.bin >> board_default_installkernel ${WORKDIR}/_.kernel.bin >>=20 >> dd of=3D$VERSATILEPB_FLASH bs=3D1M count=3D4 if=3D/dev/zero >> dd of=3D$VERSATILEPB_FLASH bs=3D1 conv=3Dnotrunc >> if=3D${WORKDIR}/first_commands >> dd of=3D$VERSATILEPB_FLASH bs=3D64k oseek=3D15 conv=3Dnotrunc >> if=3D${WORKDIR}/_.kernel.bin/boot/kernel/kernel.bin >>=20 >> The only problem for the Raspberry pi is that, if I am correct, the >> DTB is modified by the firmware (bootcode.bin) so I can=C2=B4t = statically >> compile the DTB in the kernel like for VERSATILEPB :( I would need to >> mimic what loader does and create a kernel environment variable which >> contains the address to the DTB. >>=20 >> This is a good exercice, but it doesn=C2=B4t solve my project which = is to: >>=20 >> 1/ have a self-extracting kernel or have a loader which uncompress >> the kernel, so that it takes much less time to start (my benchmark is >> raspbian or openelec).=20 >> =3D=3D> I compiled ubldr with LOADER_GZIP_SUPPORT and compressed = kernel >> to kernel.gz, reducing the size by 2. The loader does manage to load, >> uncompress and boot the kernel.gz, but the loading time is worse than >> when uncompressed, so I=C2=B4m stuck I don=C2=B4t know what=C2=B4s = wrong? >>=20 >> 2/ have the bootloader / kernel display a nice splash screen while >> the kernel boots >> =3D=3D> for that I looked at u-boot splash screen but the quality of = the >> rendering is too poor (8-bit bitmap). I looked at the VT frame buffer >> but the slash screen feature is also limited. So I might now look >> into the misc/raspberrypi-userland port and understand how the >> hello_jpeg sample code does that with the GPU, then I plan to port it >> in the kernel initialization code, not sure it=C2=B4s going to work)=20= >=20 > What version of u-boot are you using for this? I don't understand the > obsession with the time it takes to load the kernel unless something > unusual is happening. On my systems the time it takes to load a > kernel, whether it's u-boot or ubldr doing the work, is pretty much > exactly the time it takes to read the media the kernel is on. On an > sdcard that's usually a few seconds, on gigabit ethernet it tends to = be > far less than one second. But all of that assumes that caching is > enabled in u-boot, and it wasn't in some of the older ports. >=20 > When u-boot starts does it say anything about the caches being enabled > or disabled? Is the dcache command available? If not, it's probably > not enabled, and a newer u-boot may fix the problem. I hope to be > updating all our u-boot ports over the next month or so. >=20 > -- Ian From owner-freebsd-arm@freebsd.org Thu Dec 24 15:48: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 150ACA50B1B for ; Thu, 24 Dec 2015 15:48:38 +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 D38221A34 for ; Thu, 24 Dec 2015 15:48:37 +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; Thu, 24 Dec 2015 15:48:55 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBOFmZmE005842; Thu, 24 Dec 2015 08:48:35 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1450972115.25138.253.camel@freebsd.org> Subject: Re: Booting the ELF kernel without ubldr on Raspberry Pi From: Ian Lepore To: Sylvain Garrigues Cc: Tim Kientzle , freebsd-arm Date: Thu, 24 Dec 2015 08:48:35 -0700 In-Reply-To: References: <32849B9F-C7B8-4A86-B8F1-043F62D2E64C@kientzle.com> <8F62699C-126D-492D-8B7E-8C250ED5BC07@gmail.com> <1450970414.25138.238.camel@freebsd.org> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 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: Thu, 24 Dec 2015 15:48:38 -0000 On Thu, 2015-12-24 at 16:40 +0100, Sylvain Garrigues wrote: > Hello Ian, > > I¢m using u-boot from the ports (sysutils/u-boot-rpi2). It doesn¢t > display anything about cache being enabled. > > I was just comparing the time it takes to have the Linux kernel > prints its first lines, and the time it takes for the FreeBSD kernel > to print its own (the « Copyright » line) when used with u > -boot+loader. > For the former, it¢s under a second, for the latter it¢s about 3-4 > seconds (mainly spent when the loader loads the elf kernel). > > So I was wondered how they made it and was led to believe the Linux > kernel is compressed (and self-extracting), leading to less loading > time from the SD card which apparently is the bottleneck. > > So since the FreeBSD kernel has no « self-extracting » feature, and > since ubldr doesn¢t seem to support the extracting of a gzip kernel > (well it seems to work with LOADER_GZIP_SUPPORT but I see no gain), I > was trying to use the compression and extraction feature of u-boot > with the use of recent mkimage with support for lzma compression. I > thought I could boot directly a LZMA compressed kernel.bin with > mkimage, without ubldr. But I forgot about the kernel expecting a > variable with the DTB address, which is set up by ubldr, so I give up > and will wait to see if someone is interested in implementing a self > -extracting kernel in the future. > > Best, > Sylvain Don't hold your breath for a self-extracting armv6 kernel, that seems highly unlikely, especially considering that LOADER_GZIP_SUPPORT apparently works (I've been meaning to test that for months). Hmm, in our config patches for rpi2 u-boot I see +#define CONFIG_SYS_DCACHE_OFF that's probably why loading the kernel is so slow. It was probably disabled because it caused problems in ubldr, but I've developed some u -boot patches since then to do proper cache maintenance before launching standalone apps. -- Ian From owner-freebsd-arm@freebsd.org Fri Dec 25 07:06: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 7E3B7A514F0 for ; Fri, 25 Dec 2015 07:06:11 +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 4396B19C6 for ; Fri, 25 Dec 2015 07:06:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5750 invoked from network); 25 Dec 2015 06:39:36 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Dec 2015 06:39:36 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 25 Dec 2015 01:39:31 -0500 (EST) Received: (qmail 21550 invoked from network); 25 Dec 2015 06:39:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 25 Dec 2015 06:39:31 -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 3AA1BB1E001; Thu, 24 Dec 2015 22:39:23 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: 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: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@dsl-only.net> Date: Thu, 24 Dec 2015 22:39:29 -0800 To: freebsd-arm@freebsd.org, FreeBSD Toolchain 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: Fri, 25 Dec 2015 07:06:11 -0000 [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.] 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. 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.) The crash was a Bus error in /usr/local/arm-gnueabi-freebsd/bin/ar : > 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 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. > # 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 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: > 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. 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. The following shows the make.conf context that explains how = /usr/local/arm-gnueabi-freebsd/bin/ar came to be invoked: > # more /etc/make.conf=20 > 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 Other context: > # 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 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. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Dec 25 07:44: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 8C3FAA510F9 for ; Fri, 25 Dec 2015 07:44:23 +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 4900C1A2D for ; Fri, 25 Dec 2015 07:44:23 +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 1aCN2u-0001Nh-Fb; Fri, 25 Dec 2015 09:44:16 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: rpi wifi/wlan0 stopped working From: Daniel Braniss In-Reply-To: Date: Fri, 25 Dec 2015 09:44:16 +0200 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <2FD9A764-9F86-4DF1-B8F8-964678BFC21D@cs.huji.ac.il> 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: Fri, 25 Dec 2015 07:44:23 -0000 > On 24 Dec 2015, at 16:47, Adrian Chadd wrote: >=20 > try 'sysctl net.wlan.devices' ; see if urtwn0 shows up. >=20 > Newer -head removed the need for the hardware interface in ifconfig, > as it's not used. >=20 ok, it shows up. net.wlan.hwmp.inact: 5000 net.wlan.hwmp.rootconfint: 2000 net.wlan.hwmp.rannint: 1000 net.wlan.hwmp.rootint: 2000 net.wlan.hwmp.roottimeout: 5000 net.wlan.hwmp.net_diameter_traversal_time: 510 net.wlan.hwmp.maxpreq_retries: 30 net.wlan.hwmp.pathlifetime: 5000 net.wlan.hwmp.targetonly: 0 net.wlan.addba_maxtries: 3 net.wlan.addba_backoff: 10000 net.wlan.addba_timeout: 250 net.wlan.recv_bar: 1 net.wlan.mesh.maxholding: 2 net.wlan.mesh.maxretries: 2 net.wlan.mesh.backofftimeout: 5000 net.wlan.mesh.confirmtimeout: 40 net.wlan.mesh.holdingtimeout: 40 net.wlan.mesh.retrytimeout: 40 net.wlan.mesh.gateint: 10000 net.wlan.cac_timeout: 60 net.wlan.nol_timeout: 1800 net.wlan.devices: urtwn0 something must have changed in the startup, since I can not get wlan0 = started. i have in /boot/loader.conf wlan_xauth_load=3D=E2=80=9CYES=E2=80=9D in /etc/rc.conf wlans_urtwn0=3Dwlan0 ifconfig_wlan0=3D=E2=80=9CWPA SYNCDHCP=E2=80=9D cheers and season greetings danny >=20 > -a >=20 >=20 > On 24 December 2015 at 06:34, Daniel Braniss = wrote: >> with an older current, my rpi sees the wifi, and it actually works, >> with a more resent current, ifconfig does not show it. >>=20 >> when I take out the dongle: >> root@:~ # ugen0.4: at usbus0 (disconnected) >> urtwn0: at uhub1, port 4, addr 4 (disconnected) >>=20 >> when I re insert it: >>=20 >> ugen0.4: at usbus0 >> urtwn0: on = usbus0 >> urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R >>=20 >> but: >>=20 >> root@:~ # ifconfig >> lo0: flags=3D8049 metric 0 mtu 16384 >> options=3D600003 >> inet6 ::1 prefixlen 128 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 >> inet 127.0.0.1 netmask 0xff000000 >> groups: lo >> nd6 options=3D21 >> ue0: flags=3D8843 metric 0 = mtu 1500 >> options=3D80001 >> ether b8:27:eb:8e:39:ef >> media: Ethernet autoselect (none) >> status: no carrier >> nd6 options=3D29 >>=20 >> no wlan0, nada >>=20 >> any idea what I=E2=80=99m missing? >>=20 >> cheers, >> danny >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Fri Dec 25 08:31: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 E714DA5041B for ; Fri, 25 Dec 2015 08:31:44 +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 AC4681E0E for ; Fri, 25 Dec 2015 08:31:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22767 invoked from network); 25 Dec 2015 08:31:43 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 25 Dec 2015 08:31:43 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 25 Dec 2015 03:31:41 -0500 (EST) Received: (qmail 25540 invoked from network); 25 Dec 2015 08:31:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 25 Dec 2015 08:31:41 -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 DF8A2B1E001; Fri, 25 Dec 2015 00:31:41 -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: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@dsl-only.net> Date: Fri, 25 Dec 2015 00:31:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@dsl-only.net> To: freebsd-arm@freebsd.org, FreeBSD Toolchain 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: Fri, 25 Dec 2015 08:31:45 -0000 On 2015-Dec-24, at 10:39 PM, Mark Millard wrote: > [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=20 >> 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. 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. libc.so.7 is from my buildworld, including the fseeko implementation: 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 head/sys/sys/_types.h has: /* * 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; 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). 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: > (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>,=20 > _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} 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. It is my interpretation that there is nothing here to justify the memset = implementation combination: SCTLR bit[1]=3D=3D1 mixed with vst1.64 instructions I.e.: one or both needs to change unless some way for forcing 8-byte = alignment is introduced. 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). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Dec 25 08:43: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 775A2A508D4 for ; Fri, 25 Dec 2015 08:43:20 +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 C1CE61295 for ; Fri, 25 Dec 2015 08:43:18 +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 1aCNxx-00020h-8F; Fri, 25 Dec 2015 10:43:13 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: rpi wifi/wlan0 stopped working -- Solved From: Daniel Braniss In-Reply-To: Date: Fri, 25 Dec 2015 10:43:13 +0200 Cc: "freebsd-arm@freebsd.org" Message-Id: <241BE9C5-8168-4A24-BC7C-930DCED737BF@cs.huji.ac.il> References: <2FD9A764-9F86-4DF1-B8F8-964678BFC21D@cs.huji.ac.il> To: Adrian Chadd 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: Fri, 25 Dec 2015 08:43:20 -0000 > On 25 Dec 2015, at 09:44, Daniel Braniss wrote: >=20 >>=20 >> On 24 Dec 2015, at 16:47, Adrian Chadd > wrote: >>=20 >> try 'sysctl net.wlan.devices' ; see if urtwn0 shows up. >>=20 >> Newer -head removed the need for the hardware interface in ifconfig, >> as it's not used. >>=20 >=20 > ok, it shows up. > net.wlan.hwmp.inact: 5000 > net.wlan.hwmp.rootconfint: 2000 > net.wlan.hwmp.rannint: 1000 > net.wlan.hwmp.rootint: 2000 > net.wlan.hwmp.roottimeout: 5000 > net.wlan.hwmp.net _diameter_traversal_time: = 510 > net.wlan.hwmp.maxpreq_retries: 30 > net.wlan.hwmp.pathlifetime: 5000 > net.wlan.hwmp.targetonly: 0 > net.wlan.addba_maxtries: 3 > net.wlan.addba_backoff: 10000 > net.wlan.addba_timeout: 250 > net.wlan.recv_bar: 1 > net.wlan.mesh.maxholding: 2 > net.wlan.mesh.maxretries: 2 > net.wlan.mesh.backofftimeout: 5000 > net.wlan.mesh.confirmtimeout: 40 > net.wlan.mesh.holdingtimeout: 40 > net.wlan.mesh.retrytimeout: 40 > net.wlan.mesh.gateint: 10000 > net.wlan.cac_timeout: 60 > net.wlan.nol_timeout: 1800 > net.wlan.devices: urtwn0 >=20 > something must have changed in the startup, since I can not get wlan0 = started. > i have > in /boot/loader.conf > wlan_xauth_load=3D=E2=80=9CYES=E2=80=9D >=20 > in /etc/rc.conf > wlans_urtwn0=3Dwlan0 > ifconfig_wlan0=3D=E2=80=9CWPA SYNCDHCP=E2=80=9D >=20 several (GRRRR) mergemaster later and all is ok again! thanks, > cheers and season greetings > danny >=20 >=20 >>=20 >> -a >>=20 >>=20 >> On 24 December 2015 at 06:34, Daniel Braniss = wrote: >>> with an older current, my rpi sees the wifi, and it actually works, >>> with a more resent current, ifconfig does not show it. >>>=20 >>> when I take out the dongle: >>> root@:~ # ugen0.4: at usbus0 (disconnected) >>> urtwn0: at uhub1, port 4, addr 4 (disconnected) >>>=20 >>> when I re insert it: >>>=20 >>> ugen0.4: at usbus0 >>> urtwn0: on = usbus0 >>> urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R >>>=20 >>> but: >>>=20 >>> root@:~ # ifconfig >>> lo0: flags=3D8049 metric 0 mtu 16384 >>> options=3D600003 >>> inet6 ::1 prefixlen 128 >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 >>> inet 127.0.0.1 netmask 0xff000000 >>> groups: lo >>> nd6 options=3D21 >>> ue0: flags=3D8843 metric 0 = mtu 1500 >>> options=3D80001 >>> ether b8:27:eb:8e:39:ef >>> media: Ethernet autoselect (none) >>> status: no carrier >>> nd6 options=3D29 >>>=20 >>> no wlan0, nada >>>=20 >>> any idea what I=E2=80=99m missing? >>>=20 >>> cheers, >>> danny >>>=20 >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm = > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = " From owner-freebsd-arm@freebsd.org Fri Dec 25 12:26: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 74697A522D3 for ; Fri, 25 Dec 2015 12:26:57 +0000 (UTC) (envelope-from alan01346@gmail.com) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45EED1DFF for ; Fri, 25 Dec 2015 12:26:57 +0000 (UTC) (envelope-from alan01346@gmail.com) Received: by mail-ig0-x22f.google.com with SMTP id m11so93272094igk.1 for ; Fri, 25 Dec 2015 04:26:57 -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 :content-type; bh=nE68fhLm7gPTYFhlHaMRe+KdT7fAiYoUGa7APwwCWRY=; b=mQTNg/cJyoZsFs3WKCh3ZZEWgrvRheJDtL2DS2NomMzjXcyapiEAb+icZqNr8FVU8H kPbQgmV1ZUfU2saTMNS8TyP1BWG7aOfclqZL649O4/u+vHyie/T/JkSQnj04eH3ZgDE6 b/nKKbDf95ShrHGIac44TSIvCVGW/N0F9i+Q0RKfgPb/XkJGsaC6TO3urInbRQM06dis ZgkjsCYMNm926QtLx0Yctb7CApWi7Xb8EjNcOD9UAHzwdHqeGR6WEZFwqruVurhcS/Oo WCkJHGofM7wdDsPCNdvSd6W5sI9yXO+koa6kVCzz4JpMF0VDPi56gyIMBLrJPblk6zfO 8prQ== MIME-Version: 1.0 X-Received: by 10.50.160.1 with SMTP id xg1mr13339740igb.62.1451046416517; Fri, 25 Dec 2015 04:26:56 -0800 (PST) Received: by 10.107.48.208 with HTTP; Fri, 25 Dec 2015 04:26:56 -0800 (PST) Received: by 10.107.48.208 with HTTP; Fri, 25 Dec 2015 04:26:56 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Dec 2015 07:26:56 -0500 Message-ID: Subject: Re urtwn From: Alan Corey 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: Fri, 25 Dec 2015 12:26:57 -0000 I haven't used FreeBSD in a while frankly but happened to notice the urtwn post. I have several of them which seem to be from 2 different generations. OpenBSD 5.8 (the latest) has major changes to the urtwn driver. I found it easier to stick my cards in a box for now than to upgrade just for that. I was seeing unreliable performance, often an error about buffer space, and a hard crash about once a week. There is another driver in the works, don't know how long before it gets to FreeBSD. From owner-freebsd-arm@freebsd.org Fri Dec 25 14:25: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 D4650A510C2 for ; Fri, 25 Dec 2015 14:25:00 +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 99CA117E1 for ; Fri, 25 Dec 2015 14:25:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4731 invoked from network); 25 Dec 2015 14:24:58 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Dec 2015 14:24:58 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 25 Dec 2015 09:25:04 -0500 (EST) Received: (qmail 9553 invoked from network); 25 Dec 2015 14:25:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 25 Dec 2015 14:25:03 -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 0EA50B1E001; Fri, 25 Dec 2015 06:24:56 -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: Fri, 25 Dec 2015 06:24:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@dsl-only.net> To: freebsd-arm@freebsd.org, FreeBSD Toolchain 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: Fri, 25 Dec 2015 14:25:00 -0000 [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.] On 2015-Dec-25, at 12:31 AM, Mark Millard wrote: > 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=20 >>> 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>,=20 >> _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). I have (so far) removed the build tool crashes based on adding = -fmax-type-align=3D4 to avoid the misaligned accesses. Details follow. src.conf on amd64 for the rpi2 targeting buildworld/buildkernel now = looks like: > # 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=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 > 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 make.conf for during the on-rpi2 port builds now looks like: > $ more /etc/make.conf=20 > 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 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Dec 25 14:25: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 F3774A510CA for ; Fri, 25 Dec 2015 14:25:00 +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 B80B517E2 for ; Fri, 25 Dec 2015 14:25:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31889 invoked from network); 25 Dec 2015 14:25:05 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Dec 2015 14:25:05 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 25 Dec 2015 09:25:00 -0500 (EST) Received: (qmail 14342 invoked from network); 25 Dec 2015 14:25:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 25 Dec 2015 14:25:00 -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 44428B1E002; Fri, 25 Dec 2015 06:24:56 -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: Fri, 25 Dec 2015 06:24:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@dsl-only.net> To: freebsd-arm@freebsd.org, FreeBSD Toolchain 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: Fri, 25 Dec 2015 14:25:01 -0000 [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.] On 2015-Dec-25, at 12:31 AM, Mark Millard wrote: > 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=20 >>> 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>,=20 >> _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). I have (so far) removed the build tool crashes based on adding = -fmax-type-align=3D4 to avoid the misaligned accesses. Details follow. src.conf on amd64 for the rpi2 targeting buildworld/buildkernel now = looks like: > # 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=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 > 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 make.conf for during the on-rpi2 port builds now looks like: > $ more /etc/make.conf=20 > 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 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Dec 25 16:56:46 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 4747EA52F0B for ; Fri, 25 Dec 2015 16:56:46 +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 388A2139C for ; Fri, 25 Dec 2015 16:56:46 +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 tBPGuk63031722 for ; Fri, 25 Dec 2015 16:56:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 205602] arm (rpi2) context: issue identified for Bus Errors from some software (such as ar). . . Date: Fri, 25 Dec 2015 16:56:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 25 Dec 2015 16:56:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205602 Bug ID: 205602 Summary: arm (rpi2) context: issue identified for Bus Errors from some software (such as ar). . . Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net I was getting Bus Errors during attempts to build ports on a rpi2, such as during /usr/local/arm-gnueabi-freebsd/bin/ar activity. That example traced back to _fseeko use and the memset use at line 299 of /usr/src/lib/libc/stdio/fseek.c that was in use via /usr/lib/debug/lib/libc.so.7 : #0 =C2=A00x2033adcc 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 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 0x20651ea4 543497892 . . . When SCTLR bit[1] =3D=3D 1 the vst1.64 instructions require 8 byte alignmen= t but the address in r0 is only 4 byte aligned (as was the address of the start of the containing FILE structure). (FILE start address probably from a memory allocator?) I did another build/install world/kernel with "-fmax-type-align=3D4" added = and the same port now builds fine on the rpi2, no tools getting Bus Errors. (make.conf on the rpi2 also causing -fmax-type-align=3D4 to be used.) So if SCTLR bit[1]=3D=3D1 is supposed to be true/possible and if various me= mory allocator alignments are not to be to sufficiently big figures, then it app= ears that the standard clang 3.7 compile options for armv6/armv7a need to prevent presuming bigger alignment figures than 4 for pointers of unknown origin (or from memory allocators). Note: My experiments were with -march=3Darmv7a explicitly in use, not just -target armv6--freebsd11.0-gnueabi . --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Dec 25 17:57:10 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CBDFCA51561 for ; Fri, 25 Dec 2015 17:57:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9506810B3 for ; Fri, 25 Dec 2015 17:57:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x230.google.com with SMTP id to4so113932816igc.0 for ; Fri, 25 Dec 2015 09:57: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=Ptum3UTmuqyuTJI55FThy3Cpl0b8IGi9oYKCMlAAxWE=; b=Q0a54dv9IfppD/wbv/4tN4chaVq83viQZcMkaQ2Eppc2esKOcJCe/SmPhPg0nUYmHl 7lpf+scz/ihG47AxvD/x2nd/sJyttw4R4FT/lnEOsVn4nOcqTbRmL7hnCcK7qKHqO+Yc dQK9oXawSOXxK1PZcIqapvPoQHqt7xAKDd860yxWiiASUL3vcHhqkSGJrtxiBzcsM0OZ Th30NjzkPgSHsweFggSMCa0I9B6GjOMXToo3uGmgtu0HgMJvkNLNiG74NSSXoUr/csKe BPr4t5hajk0qVVJWwfYBMJpSzSTMxRBrINF83iOcAuJ+vvupgIfNC9INqunXg9Ggiyft 2Mng== MIME-Version: 1.0 X-Received: by 10.50.79.230 with SMTP id m6mr13903018igx.22.1451066230052; Fri, 25 Dec 2015 09:57:10 -0800 (PST) Received: by 10.36.121.202 with HTTP; Fri, 25 Dec 2015 09:57:09 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Dec 2015 09:57:09 -0800 Message-ID: Subject: Re: Re urtwn From: Adrian Chadd To: Alan Corey 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: Fri, 25 Dec 2015 17:57:10 -0000 is urtwn on -head giving you trouble? It shouldn't be; it should mostly work now. -a On 25 December 2015 at 04:26, Alan Corey wrote: > I haven't used FreeBSD in a while frankly but happened to notice the urtwn > post. I have several of them which seem to be from 2 different generations. > > OpenBSD 5.8 (the latest) has major changes to the urtwn driver. I found it > easier to stick my cards in a box for now than to upgrade just for that. I > was seeing unreliable performance, often an error about buffer space, and a > hard crash about once a week. There is another driver in the works, don't > know how long before it gets to FreeBSD. > _______________________________________________ > 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 Dec 25 19:53: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 54A5FA51A9E for ; Fri, 25 Dec 2015 19:53:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 1C7081BB6 for ; Fri, 25 Dec 2015 19:53:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mail-oi0-x22c.google.com with SMTP id o124so150823553oia.1 for ; Fri, 25 Dec 2015 11:53:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=2LW2LlAOFfr/9Bk4M2K8Ib+ZIOSAU2vcto1tHmfq70g=; b=COzKV8bBoC2EiAQQZF5GKe+hBixZgfil3c1crw8WQK5klXM3/nYqLGhg2EGZMt8e3w yPfILQhlMQs5oWo1lOaUXX71/td25QK1aSGlIcBgc4zXT6/grYLcxF2SbSoiSkgir4TM 9d7o3XHtZMQcnXVnNESXnMYmEg4lpeZJx6A9IVfkEf9ax7GOapgeKGyi36iwpwlWc70H VRrqF/8fbzJ+Lu26Eupv7veYBPj5XeJwPmgMEexF/0ZjURlzakMO2/rR2dBKeXVukafb ndLjW/DBoUyJ4KJ6jVJSAZm1b5DcxIxUEIe7Ytde4J9GCze4TjHYv1sBN+2p44q3zJ1Z Z4uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=2LW2LlAOFfr/9Bk4M2K8Ib+ZIOSAU2vcto1tHmfq70g=; b=F7lcF+M3cF5e7L9ptXZJqZTWMt0H1PEoUSg13zF9SPKwa5QUzI8tcS+MzDoKgjtb2X LvNBRCjIHEZOCKydW8QTfkqGOe6VYq59kBSJ3CGqXWGLnuV+fNiiQDlyEB/9kauvPfXo CEaPS1Ur9aYVBlenpPovxbQYNpxUl6clOEmumRNGBXHZqS2krMOOIt5JRXQSzhuaM3nT A0uX29w25ihrKkfaYyk8cGoBYXVkOLCXiyQO1poNPjxytMNrKHyFjNwmkdvXI/b3tF9z 4lvWfQMsct5BTKpqSz14rrSFxb2wrhqabBgRp+KzcfQwNLnxh7RQQmAeT+JZbxcc4JZA Iz7g== X-Gm-Message-State: ALoCoQlkggdTgeGsaJdYU/92yORoX3VAd347pm2nK6xBoVA2tDmQbK0Vhtxx96uewQPQr7bZkFzrWFtXGjTlwZ3MWNp3suZTuw== X-Received: by 10.202.85.195 with SMTP id j186mr23975786oib.74.1451073232546; Fri, 25 Dec 2015 11:53:52 -0800 (PST) Received: from ?IPv6:2601:280:4900:3700:e997:dd6f:8139:f929? ([2601:280:4900:3700:e997:dd6f:8139:f929]) by smtp.gmail.com with ESMTPSA id mm4sm13622866obb.1.2015.12.25.11.53.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 25 Dec 2015 11:53:51 -0800 (PST) Sender: Warner Losh 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? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B83D07DB-888A-4D4F-96E0-1636BFAA4EB5"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Warner Losh In-Reply-To: Date: Fri, 25 Dec 2015 12:53:49 -0700 Cc: freebsd-arm@freebsd.org, FreeBSD Toolchain Message-Id: <0D81C2CA-BF1C-4C14-B816-A8C5F68715B5@bsdimp.com> References: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@dsl-only.net> To: Mark Millard 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: Fri, 25 Dec 2015 19:53:54 -0000 --Apple-Mail=_B83D07DB-888A-4D4F-96E0-1636BFAA4EB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 So what happens if we actually fix the underlying bug? 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=99= s 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. 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=99t = hard coded into binaries, so even if we have to tweak the last three and deal with some =E2=80=98fak= e=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[*]... TL;DR: Why not make FILE * always 8-byte aligned? The compiler options = are a band-aide. Warner [*] 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. > 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" --Apple-Mail=_B83D07DB-888A-4D4F-96E0-1636BFAA4EB5 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 - https://gpgtools.org iQIcBAEBCgAGBQJWfZ7OAAoJEGwc0Sh9sBEABzwP/1I+blTKkKLGQXoESMEjWeio 5aSCqiKQrqx2thpeAsTDWbWBnXXfcjPY5Kgs+t5gjLMaj/oI6Lq360ySSksdGvlp 1wf7x2LTG1NiJ2oAdRBWCYs+sYW7JCjicjw1SI28rqo6o+Wno5nvrnTTLm2gnyhx GLZ2prxOXo6vCVDhU60R6vc5jj98UbtLTS6TdWlV+urLTlvRaP1jXLz2aSmVchLn hjSZVlvMgszPQR90Fh5Fa873flpbzCHcg6usy8gOU/IqMOnPC4pcEstaCTbtwbkP OMOaYZ3w8uLCESqzhM5qMriVbToKOs/ZZ9EQwHMkdlJ2qACq4umtWItyqhyhgdh5 4NsVDVJdmIOtXeGBY5uAi0fVurModb/qjhDJWGoxd4up+BmA+znPZ3GPcdLhcNUm 2W4YYu6Lx0emrA7WhHU19ZIBSe0Nb6F1LC4CCPDNUdSvCLEX9g7yjsOsmeSijbQS O/AACTVX0QdUfVHDZaPhgy9C/GVlV8zCovsFh9/1owZEngXA9BoqtSYbgMIEQxVl owF+elTanSHf+b25B7s9oBs2Vivqhg5XLWKcLU0JN69wnMg1MnEZk9e99g0qSui3 BqendD3Mm3iA2/5eZU1fIMPNpCzqv2GHyUwyGS3Vy1s8PmaEUy/OHfifHtnAx6vN k+rxdgljeSUtGkjrb4ZP =M8/v -----END PGP SIGNATURE----- --Apple-Mail=_B83D07DB-888A-4D4F-96E0-1636BFAA4EB5-- From owner-freebsd-arm@freebsd.org Fri Dec 25 22:14: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 93D35A50040 for ; Fri, 25 Dec 2015 22:14:11 +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 56D271459 for ; Fri, 25 Dec 2015 22:14:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31764 invoked from network); 25 Dec 2015 22:14:08 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Dec 2015 22:14:08 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 25 Dec 2015 17:14:10 -0500 (EST) Received: (qmail 513 invoked from network); 25 Dec 2015 22:14:10 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 25 Dec 2015 22:14:10 -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 375C11C43E4; Fri, 25 Dec 2015 14:14:04 -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: <0D81C2CA-BF1C-4C14-B816-A8C5F68715B5@bsdimp.com> Date: Fri, 25 Dec 2015 14:14:07 -0800 Cc: freebsd-arm@freebsd.org, FreeBSD Toolchain , Ian Lepore , mat@FreeBSD.org, sbruno@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <51EB4AAB-BC81-4282-BA4D-D329C41D660B@dsl-only.net> References: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@dsl-only.net> <0D81C2CA-BF1C-4C14-B816-A8C5F68715B5@bsdimp.com> 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: Fri, 25 Dec 2015 22:14:11 -0000 [I'm going to break much of the earlier "original material" text to tail = of the message.] > 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=99= s 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=99t= 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 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. "-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. But in the most fundamental terms process wise as far as I can tell. . . 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). How many other places in FreeBSD might sometimes return mis-aligned = pointers for the existing code generation and ABI combination? 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? What would it take to find out and deal with them all? (I do not have = the background knowledge to span much.) 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. Other notes: > I believe that since it has the 8-byte alignment > for a member, its size must be a multiple of 8 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. . . 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.) 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. 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. 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. My background and reference material are mostly tied the languages --and = so my notes tend to be limited to that much context. Original material: > 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" From owner-freebsd-arm@freebsd.org Fri Dec 25 23:42: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 159B4A51AB5 for ; Fri, 25 Dec 2015 23:42:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF08F19AA for ; Fri, 25 Dec 2015 23:42:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mail-oi0-x229.google.com with SMTP id y66so152117629oig.0 for ; Fri, 25 Dec 2015 15:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=4r33SfTRwWXipcaagNiw6yQTSTgqBm90O8/kDIAGj6o=; b=nBVh+F8zWGO24NnBMAKqZiM066Tp0v8wdK9rzewJkLz+9cGmKFtkQS+ED2MsDTYD+/ uj4+s6k2JzmPl7HxC7ek4ZBmhLJA3SMZyl2MIUmljULtVkzGK2jiN44jdOLKxcYoEj3d JAlKG96sRon5KCkw1AQq9SlT1KyEgf6Zri69meVwKfbr0rbFNn2gtwZ8a0LIJ+URNRY4 kP7wxvg3TyTQ7zDel/pBQWYBMA2Fqb30NBW7Foc6g6xiArYRxm4pmMJqblxtUsp+QugT o9EGpROgAXNzlvZNvqlRG6tAcege5hF/YW6Lc9RPLAsfa+V8pTNJNiB2wvW/QCWOsTJ3 a7YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=4r33SfTRwWXipcaagNiw6yQTSTgqBm90O8/kDIAGj6o=; b=Uywa4moyQEWJmWXp0trdzfNcKFAd2ov58KhdDoUAqEt34hzduk7ozwuO/A+RuzBxr7 XnxH3M0SY3nPrtr8JhGWR5zeqHdDCgPh3KKjDDRmOTnlY6drTjmyweGNWIOe3V8PLzpX Yix0Ga6Gs6cMR1VBb1NwO2zLtsCoCqycrp82JHeLQUNU4GAxYeZnH9y3AgYRXQk0L06l HlkvoWhmhm1h7221GzlKySx7uS5pRhWVoF6AfQgDU8VsB4d1rNHld2NSJt4nVtQkq+5h 8tPs7HdyIaS1AN5SYL2lt1jVfM705vnk8UbEGh84NpBznuiisJaDriiJ0YCFLaBwisjB UG4A== X-Gm-Message-State: ALoCoQmgBXX59RILBSwZE9fAkwaUJopgV96YT+3zdgmm8dEV1Lgnb3tDHl7zpmN14PNY1nionL9NuKg0daLwJjvQUbEfUtUAog== X-Received: by 10.202.73.67 with SMTP id w64mr23002113oia.84.1451086961655; Fri, 25 Dec 2015 15:42:41 -0800 (PST) Received: from ?IPv6:2601:280:4900:3700:7ce5:ac5c:f359:9182? ([2601:280:4900:3700:7ce5:ac5c:f359:9182]) by smtp.gmail.com with ESMTPSA id kp2sm10045777obb.12.2015.12.25.15.42.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 25 Dec 2015 15:42:40 -0800 (PST) Sender: Warner Losh 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? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_918263EA-3FFB-4ABA-8809-80F83519528B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Warner Losh In-Reply-To: <51EB4AAB-BC81-4282-BA4D-D329C41D660B@dsl-only.net> Date: Fri, 25 Dec 2015 16:42:38 -0700 Cc: freebsd-arm , FreeBSD Toolchain , Ian Lepore , mat@FreeBSD.org, sbruno@FreeBSD.org Message-Id: <8B52074F-FDEF-4119-BB04-630F9BE9E6DB@bsdimp.com> References: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@dsl-only.net> <0D81C2CA-BF1C-4C14-B816-A8C5F68715B5@bsdimp.com> <51EB4AAB-BC81-4282-BA4D-D329C41D660B@dsl-only.net> To: Mark Millard 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: Fri, 25 Dec 2015 23:42:43 -0000 --Apple-Mail=_918263EA-3FFB-4ABA-8809-80F83519528B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 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. 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. > 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). 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). 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. > How many other places in FreeBSD might sometimes return mis-aligned = pointers for the existing code generation and ABI combination? 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. 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. > 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? 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. > 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. The review above doesn=E2=80=99t change the ABI either. > 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. 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. > 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. It is all spelled out in the ARM EABI docs. > 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. 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. > My background and reference material are mostly tied the languages = --and so my notes tend to be limited to that much context. 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. Can you try the patch in the above code review w/o the -f switch and let = me know if it works for you? Warner > 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" --Apple-Mail=_918263EA-3FFB-4ABA-8809-80F83519528B 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 - https://gpgtools.org iQIcBAEBCgAGBQJWfdRuAAoJEGwc0Sh9sBEAg6EP/11K319mkZa0LbiV0g4Zbo5k RV44oXg/ucQsROpqDqp0DVzcMkJgGp9TjR6B0J9spviCviWJN5s6Ut5AKF9niV7g IGodpS2yaFRa7sOrv9o3ZffOOVajzOaXpkoeyeesv8+wS78B1wrpVGoKT35CC/mc SVbktqz5HpFAuPKXzCeV7ywAEpzH/NPNZFWrfT0Hi7P2UTS4KuRUemdw8adF5EDr pgARcaxIRpmUDoyU7TaRRxvrMknoqvo5vUcU5w5rLEiMrbH6pQAqdyJuDcUfa0aC 1cP/v+hjbqxFMNxTEFcQFqUgnUjrECKmOsijHJ4OCanNWK0Odiu8h4ORiyD59EyX ayTvbXMDqjiSVG449j775TkHARm8/lVJ2G4BfC4ig8AjflBDQTJpTLPxmKWS81xe Yz2uQfc6sAUKTdvG63/PwIAp1dK9ZaG2hiuSZDeGPKCVbRjFPfux3OTVj/+fUF7u IdrpturezDOhn2kfRea3IpTGeSxOTgKC1VtAx4HSUZ4GIgAiRj4xZEDl6Ww9qzaW 2GOEThC4k1pK+WL6NCoZb38pRiWONojGXErYtgs+wg+PdlXEY5heDX/6RduIs2UW 8lq+YeRGwkSHtvKt/4FnmcCSFWsEjlZ1+0uQu3VgoRZKHjnbxpASxGs7pgS7nGrU sw2TR+Xv0rOMjhVdj8v5 =qpY9 -----END PGP SIGNATURE----- --Apple-Mail=_918263EA-3FFB-4ABA-8809-80F83519528B-- From owner-freebsd-arm@freebsd.org Sat Dec 26 01:17:49 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 2D979A51932 for ; Sat, 26 Dec 2015 01:17:49 +0000 (UTC) (envelope-from alan01346@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 001B11EB7 for ; Sat, 26 Dec 2015 01:17:48 +0000 (UTC) (envelope-from alan01346@gmail.com) Received: by mail-io0-x234.google.com with SMTP id o67so267506437iof.3 for ; Fri, 25 Dec 2015 17:17:48 -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=csu7nGxIczcphfra8cgJAvJHCGZ4A06UJ+oF8qh24F8=; b=SRwlhG17W05y7Pp9YuCqcb+pXzXSzUzW1DNVLx3Z+F6cLfr9o3VHd31HoblkR2ofXj XMKqteI8OiTC8rfQ303vw51AOJcCHCbYE47s82k9XIwvos0lTnpZnf1bkZ3i4qs8fJHW vp31bFwU0lY7UDlFOrJs4+dInVdanB08sgXZHPJTbk4ILUkh6cBHOrFK5bw+OIsxats2 SRZuXTDytCTOPvy6Nfaq52y8YDlHzwZCsk/COH5+a97SNHKt2LQwSRbgZJRGLLeuqNBZ esTXBU+WAAikNm0zEC/OP6flcrKaB9GSlG+/6sTzGBYQxqrMTGii4Fhu+tYPPjIUyxpQ 5CaA== MIME-Version: 1.0 X-Received: by 10.107.128.104 with SMTP id b101mr12350804iod.37.1451092667474; Fri, 25 Dec 2015 17:17:47 -0800 (PST) Received: by 10.107.48.208 with HTTP; Fri, 25 Dec 2015 17:17:47 -0800 (PST) In-Reply-To: References: Date: Fri, 25 Dec 2015 20:17:47 -0500 Message-ID: Subject: Re: Re urtwn From: Alan Corey To: Adrian Chadd 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: Sat, 26 Dec 2015 01:17:49 -0000 No, I was just saying it had undergone a lot of work in the last 6 months or so, at least the OpenBSD drivers for it changed just about completely between 5.7 and 5.8 Don't know who actually did the work. OK, it's got a FreeBSD copyright, Kevin Lo 2014. I'm running 5.7, figures. I had noticed that the cards I bought most recently only worked with some urtwn drivers. But at under $5 each on eBay it's no big deal. I haven't booted my Pi in about 11 months, been playing with Debian on phones. The battery, display, portability, camera I wanted in my Pi in phones instead. On 12/25/15, Adrian Chadd wrote: > is urtwn on -head giving you trouble? > > It shouldn't be; it should mostly work now. > > > > -a > > > On 25 December 2015 at 04:26, Alan Corey wrote: >> I haven't used FreeBSD in a while frankly but happened to notice the >> urtwn >> post. I have several of them which seem to be from 2 different >> generations. >> >> OpenBSD 5.8 (the latest) has major changes to the urtwn driver. I found >> it >> easier to stick my cards in a box for now than to upgrade just for that. >> I >> was seeing unreliable performance, often an error about buffer space, and >> a >> hard crash about once a week. There is another driver in the works, don't >> know how long before it gets to FreeBSD. >> _______________________________________________ >> 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" > -- Credit is the root of all evil. - AB1JX From owner-freebsd-arm@freebsd.org Sat Dec 26 01:21: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 120EDA51A0E for ; Sat, 26 Dec 2015 01:21:15 +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 C5DAF1F99 for ; Sat, 26 Dec 2015 01:21:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28656 invoked from network); 26 Dec 2015 01:21:19 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 Dec 2015 01:21:19 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 25 Dec 2015 20:21:11 -0500 (EST) Received: (qmail 6825 invoked from network); 26 Dec 2015 01:21:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 26 Dec 2015 01:21:11 -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 3BDCE1C43E5; Fri, 25 Dec 2015 17:21:07 -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: <8B52074F-FDEF-4119-BB04-630F9BE9E6DB@bsdimp.com> Date: Fri, 25 Dec 2015 17:21:11 -0800 Cc: freebsd-arm , FreeBSD Toolchain , Ian Lepore , mat@FreeBSD.org, sbruno@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: 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-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 01:21:15 -0000 > 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 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. 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). 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. 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. > 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" From owner-freebsd-arm@freebsd.org Sat Dec 26 03:06: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 477C0A51FF1 for ; Sat, 26 Dec 2015 03:06:42 +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 D20191A81 for ; Sat, 26 Dec 2015 03:06:39 +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:Message-ID: Subject:To:From:Date; bh=19eaBkUdWa8foj7xVFLGuQ3Pd5Gg9J6udR+bJvfZXaM=; b=kOoo pcV/scd/x6JZinrWuKdNnc/nhJhM01NVbCDC/zLzyTseRp5deNAakYEwooIoObELD0zmoZPy29Thk z/4nMd4NMyH/XqYHY2gWx9OQ167ZP8DY0H8U8G14ofIk6RNx+kxfPvVLgW8Ye837dPIh6Khpy0GGj Pv+2KA+npwRnQ=; Received: from [114.124.26.120] (port=29254 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 1aCfBJ-003GWN-TJ for freebsd-arm@freebsd.org; Fri, 25 Dec 2015 20:06:10 -0700 Date: Sat, 26 Dec 2015 11:05:45 +0800 From: Erich Dollansky To: freebsd-arm@freebsd.org Subject: differences in top's bookkeeping between 10.2 and 11 Message-ID: <20151226110545.4eebe841@X220.alogt.com> 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: Sat, 26 Dec 2015 03:06:42 -0000 Hi, I do not know if this is of any interest. I have a test program which starts 1000 threads which use a tiny amount of CPU time every second. This all works fine, only top surprises me a bit. FreeBSD raspberry0.alogt.com 10.2-STABLE FreeBSD 10.2-STABLE #0 r291083: Fri Nov 20 09:20:23 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm reports: load averages: 119.74, 76.30, 53.35 and 1046 root 1001 40 0 165M 33664K umtxn 3:38 0.05% test and idle shows values between 30 and 50%. while FreeBSD raspberry2.alogt.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r291495: Tue Dec 1 09:13:20 UTC 2015 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI2 arm reports: load averages: 4.63, 7.64, 4.79 and 1360 root 1001 38 0 199M 47928K uwait 1 2:24 35.89% test and idle shows values around 80 to 90%. The program reaches the hardware limits on 10.2 but top claims that it takes less than 1% of CPU time. The 30 to 40% as claimed under 11 sounds much more reasonable to me. I have read of top's bookkeeping habits but never saw it that extreme. Erich From owner-freebsd-arm@freebsd.org Sat Dec 26 04:32: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 CDC57A515B5 for ; Sat, 26 Dec 2015 04:32:16 +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 88FAB1C44 for ; Sat, 26 Dec 2015 04:32:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25657 invoked from network); 26 Dec 2015 04:32:13 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 26 Dec 2015 04:32:13 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 25 Dec 2015 23:32:19 -0500 (EST) Received: (qmail 30084 invoked from network); 26 Dec 2015 04:32:19 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 26 Dec 2015 04:32:19 -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 829F51C43BC; Fri, 25 Dec 2015 20:32:07 -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: Fri, 25 Dec 2015 20:32:12 -0800 Cc: freebsd-arm , FreeBSD Toolchain , Ian Lepore , mat@FreeBSD.org, sbruno@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: 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-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 04:32:17 -0000 [I am again breaking off another section of older material.] Mixed news I'm afraid. 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. 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: > --- _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>:=09 > vst1.64 {d16-d17}, [r4]! > . . . > (gdb) info all-registers > r0 0xbfbf81a8 -1077968472 > r1 0x22f07e14 586186260 > r2 0xc416bc 12850876 > r3 0x2 2 > r4 0x22f07dfc 586186236 > . . . 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. 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. 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. Older material: On 2015-Dec-25, at 5:21 PM, Mark Millard wrote: > 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 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. 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). 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. 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. > 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" From owner-freebsd-arm@freebsd.org Sat Dec 26 16:45:39 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 442BFA520E5 for ; Sat, 26 Dec 2015 16:45:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 04CAA1F50 for ; Sat, 26 Dec 2015 16:45:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mail-oi0-x230.google.com with SMTP id l9so129230402oia.2 for ; Sat, 26 Dec 2015 08:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=MafQe3JvzPs7LCo3zWvMQI+8oUDIOVswkIZw0ddqrnQ=; b=WU0ltwcHWk8RCVwg4XOi/r8zgWs1Q3mSL3bM00siP2n3DRJbx2AU7QznTe1py8S0ua Y8Uj7OqII5UYFrVjyFvsV2nfR3j7TNoEKXg+IFjsnAibUuv3JN+ssjwN4nBNhssQrwW5 UR7F8BDHUXAMlYpMxmjfwTn3IrosJyBTNXbQ153dVNQHbdsHhH5b5c1Jvu2SResJX5dr /1BjVnx64vHBf32AfZz9mZFDPJeo9AtFFb/2/GOQUehGCD8x87k4QBZdpDp32Ke3qOqF Mqk16DbECA2rQVnQ440UYFN6w7JGelbCoqZ6Ryiffa0oWZlGQhObQJ8MwNDP64BGkt2I rNdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=MafQe3JvzPs7LCo3zWvMQI+8oUDIOVswkIZw0ddqrnQ=; b=aQjen0kj45Fxe5YcSYLxMJl/2JSHzBNIW8z4LUWU3nAGYM0dVC1f+ymOkzQZ0caJ6Z MwCpeA17AcXtAK2C6CpfS4wob0NZ1mWYv26QFQ++nfcbIFKeL4jNIiK3Uhd6xVFMdBTg jAuiZ8Xe10nGcUBVcokQwfJbtcAFp4kgQnn0ByFxmVjwE1ER5yD1/NLG/nzWpolUXn5X aseJcc15bj4DUcXAg1LO3ifwyR1qBdzwnDy8f/dvxUckGy7MLInwZhdT6O5TIqCceq85 +tMZmx/J0rCVaBR2gGV/jqsNTDL2/OJJAE/zi1dqjU789wiR3f1P0K4VL+wYLlbOShKw y0aA== X-Gm-Message-State: ALoCoQlSP/bHsY8j4KXc8MNGeCZSKzHeYN+zJ0gvdzAGiTo/Yknfw40SBZLrFPjczPmg8sr/vQwzPn/ApJAxbCGWvvMVy44RXA== X-Received: by 10.202.229.132 with SMTP id c126mr25328023oih.112.1451148337712; Sat, 26 Dec 2015 08:45:37 -0800 (PST) Received: from ?IPv6:2601:280:4900:3700:f8f5:b3fe:63a6:7f79? ([2601:280:4900:3700:f8f5:b3fe:63a6:7f79]) by smtp.gmail.com with ESMTPSA id bi2sm15493726obb.24.2015.12.26.08.45.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 26 Dec 2015 08:45:36 -0800 (PST) Sender: Warner Losh 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? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3A881A22-5ED1-4B30-8C08-758FA0B9A7D1"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Warner Losh In-Reply-To: Date: Sat, 26 Dec 2015 09:45:31 -0700 Cc: freebsd-arm , FreeBSD Toolchain , Ian Lepore , mat@FreeBSD.org, sbruno@FreeBSD.org Message-Id: 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: Mark Millard X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 16:45:39 -0000 --Apple-Mail=_3A881A22-5ED1-4B30-8C08-758FA0B9A7D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, it sounds like I fixed a bug, but there=E2=80=99s more. What were the specific port so I can test it here? And to be clear, this is a buildworld on the RPi 2 using the cross-built = world with CPUTYPE=3Darmv7a or some such, right? Warner > 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 >=20 >=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 --Apple-Mail=_3A881A22-5ED1-4B30-8C08-758FA0B9A7D1 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 - https://gpgtools.org iQIcBAEBCgAGBQJWfsQsAAoJEGwc0Sh9sBEAXM0QAKRH78oT70ZQFQDPar9s9qIc LJBzzu5FaK4R+Ztv+t1ypx1dx8CLUUOkji/GXrKGnEblY2AwAoGv2deAC5Y6Q5AE N/vd5p4V8Z11iKrH/YqFakBoFabdtbtl+gjHLyEBZMH6jjqI9s+8oA71LOwyPsX6 5rutJPHFAP4HYGTNMv9Jn9vF5mr4CyCtgHw6VNyB8PW9rbNX+a9Ox3dlwkgWqLes RDpVri0Sc0QYCaagfvnZHqsuww8W+MYL9TnT2ioArQZVhECZCrYh5NcCP2JiiyX7 Tq/4+lXroggDDY45BTZq+M1dhlJf57DCJf84oqFx0f/+ygoEODC83FRfnQPFAA2M y+5HwlyDaThfY7387/IgyBPIH2T6zC/xj1JiXwRNPVjtJPsSRlYfomCyNeEQTZwu gM3LJXfJCvxCyYh2f7yYbPAdZu9AbLDJctVsqgRhy22jy/l/xfcOmdi7UzaLMdDq gaBbekcp+VwAojeciJU0baOu1uwWBT4FNx3ErhzmjND+2oDCWWt7JH2jpEiUVpt/ Wbo0avYU4QZW2K5qJjgcIwDRWLZRFnR+fWQJ81accWMOAYANHcWZDrYK97lAPaUV QfQf7fXOtZ3lfxdLqoS/oBEzmmpnj/qR9Uni8faFzrQJQvt9CBbJDXo2vZCjmcT7 CjUy0akjLstzZ12O7RN8 =l7Th -----END PGP SIGNATURE----- --Apple-Mail=_3A881A22-5ED1-4B30-8C08-758FA0B9A7D1-- From owner-freebsd-arm@freebsd.org Sat Dec 26 17:00:22 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 DF11CA5251C for ; Sat, 26 Dec 2015 17:00:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (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 BAD1D1398 for ; Sat, 26 Dec 2015 17:00:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sat, 26 Dec 2015 16:59:41 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBQH0DWq010253; Sat, 26 Dec 2015 10:00:14 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1451149213.25138.271.camel@freebsd.org> 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: Ian Lepore To: Mark Millard , Warner Losh Cc: mat@FreeBSD.org, freebsd-arm , FreeBSD Toolchain Date: Sat, 26 Dec 2015 10:00:13 -0700 In-Reply-To: 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> 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: Sat, 26 Dec 2015 17:00:23 -0000 On Fri, 2015-12-25 at 17:21 -0800, Mark Millard wrote: > 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. > > 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. After reading the docs more carefully, I think -mno-unaligned-access isn't a bigger hammer, it's just a different tool that addresses a different problem than the one you ran into, and it's one we need. In particular, it prevents alignment-required accesses to potentially unaligned fields in a struct marked as 'packed', which is something we rely on (it's why we mark some structs as packed). -- Ian From owner-freebsd-arm@freebsd.org Sat Dec 26 19:07: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 52AC5A526B8 for ; Sat, 26 Dec 2015 19:07:57 +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 1351F15DE for ; Sat, 26 Dec 2015 19:07:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2835 invoked from network); 26 Dec 2015 19:07:49 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 Dec 2015 19:07:49 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 26 Dec 2015 14:07:48 -0500 (EST) Received: (qmail 6369 invoked from network); 26 Dec 2015 19:07:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 26 Dec 2015 19:07:47 -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 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 6B8A1B1E001; Sat, 26 Dec 2015 11:07:45 -0800 (PST) Content-Type: text/plain; charset=us-ascii 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: <1451149213.25138.271.camel@freebsd.org> Date: Sat, 26 Dec 2015 11:07:48 -0800 Cc: Warner Losh , mat@FreeBSD.org, freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <6EC8F626-D8C4-435E-B67A-CA841C9C1322@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> <1451149213.25138.271.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 19:07:57 -0000 On 2015-Dec-26, at 9:00 AM, Ian Lepore wrote: > On Fri, 2015-12-25 at 17:21 -0800, Mark Millard wrote: >> 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 > After reading the docs more carefully, I think -mno-unaligned-access > isn't a bigger hammer, it's just a different tool that addresses a > different problem than the one you ran into, and it's one we need. In > particular, it prevents alignment-required accesses to potentially > unaligned fields in a struct marked as 'packed', which is something we > rely on (it's why we mark some structs as packed). >=20 > -- Ian >=20 >=20 If clang uses the same interpretation as gcc for arm then I agree: > -munaligned-access > -mno-unaligned-access > Enables (or disables) reading and writing of 16- and 32- bit values = from addresses that are not 16- or 32- bit aligned. By default unaligned = access is disabled for all pre-ARMv6 and all ARMv6-M architectures, and = enabled for all other architectures. If unaligned access is not enabled = then words in packed data structures are accessed a byte at a time. I see that linux went with SCTLR bit[1] being cleared for >=3D armv6 for = the kernel: = http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3D= 8428e84d42179c2a00f5f6450866e70d802d1d05 Interestingly clang -cc1 -help only mentions -mno-unaligned-access as a = note to -mstrict-align: > # clang++ -cc1 -help | grep align > -fmax-type-align=3D > Specify the maximum alignment to enforce on = pointers lacking an explicit alignment > -fno-bitfield-type-align > Ignore bit-field types when aligning = structures > -fpack-struct=3D Specify the default maximum struct packing = alignment > -mstack-alignment=3D > Set the stack alignment > -mstackrealign Force realign the stack at entry to every = function > -mstrict-align Force all memory accesses to be aligned = (same as mno-unaligned-access) Also -munaligned-access is not mentioned at all. Apparently "clang -cc1 = -help" does not generally document gcc compatibility syntax. gcc's AArch64 page = https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options = only mentions -mstrict-align : "Do not assume that unaligned memory = references are handled by the system". (Not as explicit for = interpretation as the earlier-quoted arm wording.) gcc's arm page = https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#ARM-Options only = mentions -munaligned-access and -mno-unaligned-access (as quoted = earlier), not -mstrict-align . powerpc's page at = https://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html#RS= _002f6000-and-PowerPC-Options only mentions -mstrict-align and = -mno-strict-align : "On System V.4 and embedded PowerPC systems do not = (do) assume that unaligned memory references are handled by the system". It looks like being compatible for the command line syntax requires = separate cases across architectures, especially when spanning both clang = and gcc. From owner-freebsd-arm@freebsd.org Sat Dec 26 20:51:49 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 8004FA523C0 for ; Sat, 26 Dec 2015 20:51:49 +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 336911EB1 for ; Sat, 26 Dec 2015 20:51:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20400 invoked from network); 26 Dec 2015 20:51:53 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 26 Dec 2015 20:51:53 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 26 Dec 2015 15:51:48 -0500 (EST) Received: (qmail 4015 invoked from network); 26 Dec 2015 20:51:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 26 Dec 2015 20:51:48 -0000 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 D4113B1E001 for ; Sat, 26 Dec 2015 12:51:42 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: fyi: 11.0-current rpi2 systat -vmstat shows around 24k interrupts for bcm283x_dw Message-Id: <0A781C7D-C5F5-4931-AE38-D2FEC0848DCA@dsl-only.net> Date: Sat, 26 Dec 2015 12:51:46 -0800 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: Sat, 26 Dec 2015 20:51:49 -0000 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. > 2 users Load 0.01 0.02 0.00 Dec 26 20:33 >=20 > Mem:KB REAL VIRTUAL VN PAGER = SWAP PAGER > Tot Share Tot Share Free in out = in out > Act 29944 6384 199516 7404 27876 count > All 34164 8100 225364 26156 pages =20 > Proc: = Interrupts > r p d s w Csw Trp Sys Int Sof Flt ioflt 24461 = total > 23 502 6 36 24k 100 cow = mbox0 1 > zfod = vchiq0 2 > 0.1%Sys 0.0%Intr 0.0%User 0.0%Nice 99.8%Idle ozfod 24118 = bcm283x_dw > | | | | | | | | | | %ozfod = bcm_dma0 > daefr = uart0 65 > 8 dtbuf prcfr = sdhci_bcm0 > Namei Name-cache Dir-cache 64790 desvn totfr 232 = generic_ti > Calls hits % hits % 64150 numvn react 111 = ipi 76 > 3 3 100 38416 frevn pdwak > 1 pdpgs > Disks mmcsd md0 da0 intrn > KB/t 0.00 0.00 0.00 195896 wire > tps 0 0 0 2620 act > MB/s 0.00 0.00 0.00 711648 inact > %busy 0 0 0 cache > 27876 free > 88292 buf =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat Dec 26 22:55:56 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 140DEA52135 for ; Sat, 26 Dec 2015 22:55:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4B2F158B for ; Sat, 26 Dec 2015 22:55:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x230.google.com with SMTP id 186so283622965iow.0 for ; Sat, 26 Dec 2015 14:55:55 -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=YI43NukjCg5+ZzoQNo62Cdj6X79YU7CYpLXfm1aQl3g=; b=ziWdFfLq+Vxv2ejOvVNCTsEFOZSB06JnxymbIG2MRAmJJ2kuCrotLYt/rhbVFuSPgm MfCkQk+ya2PQt3jdQz2FfwycBl7cn9W656aM9Tk2z60rvl1na6O/RxECMlbHqKNZ0EgZ j5amyOKCue7ONbSlflLY8IzUnCzZyPGq8nfSTkSEia3iQ7lEzoqTOsJD+8t/GHbqRTKN IZEwM2kmfq+KnPo4FwV3swmk5YN4rK6EymRqqDIobknrrKF/csncwCAxC0Qm/Xe8V9/J BvZC4wTLea+HkBUijKOjRJJ5BKg2Pbv9B7x0PVVMma1VfaeXEm/ya6lDNqoBjEIq8hZa bZvQ== MIME-Version: 1.0 X-Received: by 10.107.10.217 with SMTP id 86mr35465434iok.75.1451170555203; Sat, 26 Dec 2015 14:55:55 -0800 (PST) Received: by 10.36.121.202 with HTTP; Sat, 26 Dec 2015 14:55:55 -0800 (PST) In-Reply-To: <0A781C7D-C5F5-4931-AE38-D2FEC0848DCA@dsl-only.net> References: <0A781C7D-C5F5-4931-AE38-D2FEC0848DCA@dsl-only.net> Date: Sat, 26 Dec 2015 14:55:55 -0800 Message-ID: Subject: Re: fyi: 11.0-current rpi2 systat -vmstat shows around 24k interrupts for bcm283x_dw From: Adrian Chadd To: Mark Millard Cc: freebsd-arm 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: Sat, 26 Dec 2015 22:55:56 -0000 What's teh output of 'vmstat -ia' ? -a From owner-freebsd-arm@freebsd.org Sat Dec 26 23:02: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 1CB1DA522E4 for ; Sat, 26 Dec 2015 23:02:32 +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 D659A1ADD for ; Sat, 26 Dec 2015 23:02:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22980 invoked from network); 26 Dec 2015 23:02:36 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 Dec 2015 23:02:36 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 26 Dec 2015 18:02:28 -0500 (EST) Received: (qmail 5107 invoked from network); 26 Dec 2015 23:02:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 26 Dec 2015 23:02:27 -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 8C7D2B1E001; Sat, 26 Dec 2015 15:02:24 -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: Date: Sat, 26 Dec 2015 15:02:28 -0800 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <85B1DF09-7D67-4031-B1E9-E4754CDC690A@dsl-only.net> References: <0A781C7D-C5F5-4931-AE38-D2FEC0848DCA@dsl-only.net> 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: Sat, 26 Dec 2015 23:02:32 -0000 On 2015-Dec-26, at 2:55 PM, Adrian Chadd wrote: > > What's teh output of 'vmstat -ia' ? > > > -a > # 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 === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat Dec 26 23:07: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 AF747A523C8 for ; Sat, 26 Dec 2015 23:07:43 +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 414A91B9A for ; Sat, 26 Dec 2015 23:07:42 +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 2B3262297FA for ; Sat, 26 Dec 2015 16:59:29 -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> From: Karl Denninger Message-ID: <567F1BCB.8080609@denninger.net> Date: Sat, 26 Dec 2015 16:59:23 -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: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010504070804030805000601" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 23:07:43 -0000 This is a cryptographically signed message in MIME format. --------------ms010504070804030805000601 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable interrupt total rate 0 0 irq1: mbox0 27 0 irq2: vchiq0 2 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 51925940 172 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 97728 43 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 3659 2 0 0 0 0 0 0 0 0 irq70: sdhci_bcm0 12026 5 0 0 irq72: generic_time 0 0 irq73: generic_time 505978 225 0 0 irq75: generic_time 0 0 irq76: ipi 243562 108 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 =2E... Total 52788922 23444 Hmmm... I wonder if this is related to the bcm sound driver going "mute" and needing a reboot to recover? On 12/26/2015 16:55, Adrian Chadd wrote: > What's teh output of 'vmstat -ia' ? > > > -a > _______________________________________________ > 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" --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms010504070804030805000601 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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMjYyMjU5MjRaME8GCSqGSIb3DQEJBDFCBEAi iZGoPLD2Ie/kE1gYyDdxudgu6lUAujcFu940eymVwsw+JDJlWzxpguFGGUBmMnYmAeK4jq8U i9WVEKZxpfS0MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAKwJ1pERT g5TPzzbbaEP7e9GtOfkboJrhK/V5MWNA/l29UoX7JG1oY6a9qzltxVfSSllPltXtQgcVcbM/ vpCk0TKSC5mhqmCKsij+LD8JaTP73Ka1OQxS13WZWhk1oArWMoLd/QAdf9Y5t4ydFUUIHpyI nxyNxV1oSaNGs9KYMJvFaGzfXvTi7uYvSaUyRTyaV21YjTqtW+3lwBVE6pRoq/tcJDmTEXCA 7PlnOwu9UBj9uXzkuVwy/etqK6NVPNaHnhcMevB9rEFC3TLLjNjMUkUfmxiuW8t7S8BE+bDR hDSsnUwyEkNjm8mXVMwhnR76oCa+ruOD7/4nQakFc/F1DfjwL7IKgSe6TQZBYBlCYJ8NQ7/M mQfsvIPKDk37dPPVtNmIH8VJHpr23WwEwcyWuxy1+YtYDrACseTPeVCpGZ3p8jJUOA/XKfNB voLPxt6JBqCBePXT3S5nBECnil7LECoH+FAUHM/awTbXygNo8luj+sYr2Zfa6u6rvqg22g62 brk/4rLJbhuv3W9DbzEet+AZhOeiojczuQSbB6NO0ypjoQ5suJpWlQYZTdTcawGegAb6wcKF 2Ha+7r4oenX0H7jTV77dBw/+AWWSn9A0W0a/1SumumJV8NsgCER0erV6yBc9725zmiO6HILA zUx30ndAFXSAUv4hInXKk653uQUAAAAAAAA= --------------ms010504070804030805000601--