From owner-freebsd-arm@freebsd.org Sun Aug 6 21:19:17 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D0FEDCA5BD for ; Sun, 6 Aug 2017 21:19:17 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward9o.cmail.yandex.net (forward9o.cmail.yandex.net [37.9.109.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B70426E54E for ; Sun, 6 Aug 2017 21:19:16 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from mxback15g.mail.yandex.net (mxback15g.mail.yandex.net [77.88.29.94]) by forward9o.cmail.yandex.net (Yandex) with ESMTP id E74E22188E for ; Mon, 7 Aug 2017 00:19:05 +0300 (MSK) Received: from mxback15g.mail.yandex.net (localhost.localdomain [127.0.0.1]) by mxback15g.mail.yandex.net (Yandex) with ESMTP id BF56470E25F7 for ; Mon, 7 Aug 2017 00:19:05 +0300 (MSK) Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [2a02:6b8:0:1a2d::27]) by mxback15g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id LczmiTuSew-J5guiPhI; Mon, 07 Aug 2017 00:19:05 +0300 Received: by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 5WKxo3Vwu0-J5oW2fu3; Mon, 07 Aug 2017 00:19:05 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1502054345; bh=gSS+o5UIRI/DtrlivxzIwyJhyl1RZWPOtTu8WEHE5js=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=ZFeof81ypuwF0uxm1QKDxybEBtiCAWjZAh/BCGAd5hL0u7j1Uo+IKOwCkn+E3p3i4 iaedhVbitfJNePWDB89jggPU5FZ0nIQpyWD56ilwkN2hGS0l6/Zgvv5WTw1Unrj4Sn eoFmL9F1RZGDpCeoyniSdKovjrkukS14bc+ctWZk= Authentication-Results: smtp3o.mail.yandex.net; dkim=pass header.i=@passap.ru X-Yandex-Suid-Status: 1 0 Subject: Re: boot.ini file for Odroid-C1 on FreeBSD wiki page To: freebsd-arm@freebsd.org References: From: Boris Samorodov Message-ID: <26c67e40-8b90-57f1-de32-e60d1cffe1b9@passap.ru> Date: Mon, 7 Aug 2017 00:19:04 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: ru-RU Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 21:19:17 -0000 04.08.2017 09:15, Yoshiro MIHIRA пишет: > I will add boot.ini information to FreeBSD wiki page(1), if no one reply my > email until 10/Aug. That will be great. I have some more questions/fixes to "Steps to prepare SD card". 1. There are two commands: --- gpart add -t fat16 -b 1134 -s 64M mmcsd0 gpart add -t freebsd -b 132174 mmcsd0 --- I doubt the second command is precise. 64M is 131072 blocks, 131072 + 1134 = 132206. If I use those commands I get the error after the second one: --- gpart: autofill: No space left on device --- The value 132206 has a success. So the second command should be: --- gpart add -t freebsd -b 132206 mmcsd0 --- 2. Since we prepare the final disk, I'd add a growfs command at the end of those steps: --- growfs /dev/mmcsd0 --- HTH & WBR -- bsam From owner-freebsd-arm@freebsd.org Sun Aug 6 22:33:25 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F82FDCE50F for ; Sun, 6 Aug 2017 22:33:25 +0000 (UTC) (envelope-from specials@furthermore.co.za) Received: from furthermoreincconsultancy.co.za (mta4.furthermoreincconsultancy.co.za [62.75.228.86]) by mx1.freebsd.org (Postfix) with ESMTP id 0C01071331 for ; Sun, 6 Aug 2017 22:33:24 +0000 (UTC) (envelope-from specials@furthermore.co.za) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=mail; d=furthermoreincconsultancy.co.za; h=Date:Message-ID:From:To:Subject:MIME-Version:Content-Type; i=postmaster@furthermoreincconsultancy.co.za; bh=6UoWvTgtjMc9qsLxqLh5N7NSw7I=; b=P7poKpCQjLqNssow8X9eymkYThiuI+H0WNMCT7Isdtm6mOtZ2FrZk1KJvVTy1ZFLBoj6QkvcHQp0 ZUVhGBpHirkT+M7iKs9q7CG1sDk926kBPe21bd+lT2lESlPccz4uOdQOPVf5fhbyjvaYDaXqugLF eq/uLeaOfWZGFlFE8hc= Received: from specials@furthermore.co.za (41.164.39.47) by furthermoreincconsultancy.co.za id hgucja0001gr for ; Mon, 7 Aug 2017 00:33:23 +0200 (envelope-from ) Date: Mon, 07 Aug 2017 00:33:23 +0200 Message-ID: <2017870332372AMUNIQUEID@USER-PC> From: i5 Desktop Special To: freebsd-arm@freebsd.org Subject: i5 Desktop Special - EXTENDED TILL TUES 8 AUG - R3999 X-Mailer: AutoMSW (www.automsw.com) ID: 1386816 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 22:33:25 -0000 i5 Desktop PC - only R3999 = EXTENDED TILL TUESDAY 8 AUG 2017 5 Desktop PC 350GB Hard Drive 4GB Memory = 3.1GHZ Intel=AE Core=99 i5-650 Processor 8 x USB Slots DVD Reader/Writer Installed with Windows 7 System FREE APPS (VLC / Adobe Reader / Open Office) FREE Keyboard and Mouse This desktop is designed for powerful use, and is suitable for many purpos= es such as GAMING, OFFICE PC, DESIGNING WORK, ETC. = It is powerful enough to handle a lot of work load, and will NOT let you d= own, regardless of your requirements. The small design lets you use it in very tight spaces, such as a bedroom, = office cubicles, limited desk space. It is a robust desktop, so it can be used=A0 without fear of damage to the= casing, or internal components. It come fully installed with Windows 7, and Open Office, so you can start = using it IMMEDIATELY REASONS TO OWN THIS PC Incredible Performance Boosts productivity Green Features =96 Uses very little resources to run = Ergonomic Design Industrial quality design and materials Suitable for everyone FREE EXTRAS USB Keyboard USB Mouse Programmes Pre-Installed Windows 7 64bit Open Office Adobe Reader VLC Media Player =A0Email us today on desktop@products-sales.co.za for more information or = to purchase or call 021 903 0501 / 021 903 0118 =A0Renewed/refurbished to brand new. No Monitor included =A0Delivery to your door via courier or collection can be arranged (R99) =A0 =A0OFFER VALID TILL TUESDAY 8 AUG 2017 ONLY!! =A0_______________________________________________________ Why am I receiving this message? 1. You subscribed on one of our many related websites 2. A friend has forwarded you this message 3. You have had previous communications with one of our linked websites. = Eg. You have requested quotes/bookings/info regarding related products fro= m us How do I Unsubscribe? Reply to this e-mail with the word "Unsubscribe" =A0 Notes: Pictures are a representation of the item, but might differ with certain a= spects All prices are subject to change without notice Stock levels are not guaranteed and items might be place on back-order Courier charges are estimates, all courier charges will be quoted per orde= r. By accepting this email without unsubscribing, possible further marketing = emails will be sent to you. From owner-freebsd-arm@freebsd.org Mon Aug 7 08:58:56 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EA88DC52D1 for ; Mon, 7 Aug 2017 08:58:56 +0000 (UTC) (envelope-from abologna@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 252BC1F68 for ; Mon, 7 Aug 2017 08:58:56 +0000 (UTC) (envelope-from abologna@redhat.com) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 171C76E814; Mon, 7 Aug 2017 08:58:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 171C76E814 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=abologna@redhat.com Received: from ovpn-204-221.brq.redhat.com (ovpn-204-221.brq.redhat.com [10.40.204.221]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BC24E8D56C; Mon, 7 Aug 2017 08:58:51 +0000 (UTC) Message-ID: <1502096328.3143.2.camel@redhat.com> Subject: Re: virtio-net issues on aarch64 QEMU/KVM From: Andrea Bolognani To: Mark Rutland Cc: freebsd-arm@freebsd.org, Andrew Turner Date: Mon, 07 Aug 2017 10:58:48 +0200 In-Reply-To: <20170804132950.GA9477@remoulade> References: <1501165794.4378.8.camel@redhat.com> <20170804132950.GA9477@remoulade> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 07 Aug 2017 08:58:55 +0000 (UTC) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 08:58:56 -0000 On Fri, 2017-08-04 at 14:29 +0100, Mark Rutland wrote: > As a (vaguely-related) heads-up, you will find that 11.1 will not work as an > SMP KVM guest, as it doesn't enable SGIs for the boot CPU in the GIC > distributor, leading to a lockup later in the boot process. I think Andrew > Turner is currently looking at fixing that. Yeah, I noticed that. Glad to hear a fix is in the works. > I dumped a stacktrace using QEMU's gdbserver; it looks like FreeBSD is polling > the virtio queue waiting for something: > > #0 0xffff000000170294 in VIRTIO_BUS_POLL (dev=0xfffffd00005ab900) at ./virtio_bus_if.h:159 > #1 virtqueue_poll (vq=0xffff00004083e000, len=0x0) at /usr/src/sys/dev/virtio/virtqueue.c:573 > #2 0xffff00000017707c in vtnet_ctrl_mac_cmd (sc=0xfffffd00004fa000, hwaddr=) at /usr/src/sys/dev/virtio/network/if_vtnet.c:3163 > #3 vtnet_set_hwaddr (sc=0xfffffd00004fa000) at /usr/src/sys/dev/virtio/network/if_vtnet.c:3588 > #4 0xffff000000176568 in vtnet_reinit (sc=0xfffffd00004fa000) at /usr/src/sys/dev/virtio/network/if_vtnet.c:3022 > #5 vtnet_init_locked (sc=0xfffffd00004fa000) at /usr/src/sys/dev/virtio/network/if_vtnet.c:3069 > #6 0xffff000000175ff8 in vtnet_ioctl (ifp=0xfffffd000058f000, cmd=, data=) at /usr/src/sys/dev/virtio/network/if_vtnet.c:1107 > #7 0xffff000000373e60 in ifhwioctl (cmd=, ifp=, td=, data=) at /usr/src/sys/net/if.c:2456 > #8 ifioctl (so=, cmd=2149607696, data=0xffff000054ae1888 "vtnet0", td=) at /usr/src/sys/net/if.c:2836 > #9 0xffff0000002f3b14 in fo_ioctl (fp=, com=2149607696, active_cred=, td=, data=) at /usr/src/sys/sys/file.h:323 > #10 kern_ioctl (td=0xfffffd0000a7f000, fd=3, com=2149607696, data=0xffff000054ae1888 "vtnet0") at /usr/src/sys/kern/sys_generic.c:836 > #11 0xffff0000002f377c in sys_ioctl (td=0xfffffd0000a7f000, uap=0xffff000054ae1978) at /usr/src/sys/kern/sys_generic.c:745 > #12 0xffff000000555408 in syscallenter (td=, sa=) at /usr/src/sys/arm64/arm64/../../kern/subr_syscall.c:135 > #13 svc_handler (frame=, td=) at /usr/src/sys/arm64/arm64/trap.c:139 > #14 do_el0_sync (td=0xfffffd0000a7f000, frame=) at /usr/src/sys/arm64/arm64/trap.c:366 > > ... unfortunately I'm not all that familiar with how virtio works, so I'm not > sure which end is doing the wrong thing. Me neither :) I'll forward the information to my colleagues that work on QEMU though, hopefully they'll figure out what's wrong. -- Andrea Bolognani / Red Hat / Virtualization From owner-freebsd-arm@freebsd.org Mon Aug 7 18:38:50 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01637DC0BD2 for ; Mon, 7 Aug 2017 18:38:50 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward17o.cmail.yandex.net (forward17o.cmail.yandex.net [37.9.109.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ACF3E7CCA5 for ; Mon, 7 Aug 2017 18:38:49 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from mxback14j.mail.yandex.net (mxback14j.mail.yandex.net [IPv6:2a02:6b8:0:1619::90]) by forward17o.cmail.yandex.net (Yandex) with ESMTP id C5DA422B24 for ; Mon, 7 Aug 2017 21:38:45 +0300 (MSK) Received: from smtp1p.mail.yandex.net (smtp1p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:6]) by mxback14j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 68EAxJmhS0-cjwCSqOT; Mon, 07 Aug 2017 21:38:45 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1502131125; bh=ScV/Jeg8TJzpObOL9fjcye1XGYg2YYxE4e63lPEGRNg=; h=To:From:Subject:Message-ID:Date; b=Ewl+8QyzldmPPqm3e12B1ihpIzv9YfNBD8xHJvuvjv61zD0VRAIoGeBpYPpbGDJLM gxatV48R2KfZuWxaxJpekc+oeaXGVA0jw13fxvU5BCOE/IHT5XPtyqUeYNEFzN4cpX heUdmfRQvH6J6/TwwPOSj6rk2xo9chtlB90dxU5U= Received: by smtp1p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id gmyV9RBo1a-cjs0WUgk; Mon, 07 Aug 2017 21:38:45 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passap.ru; s=mail; t=1502131125; bh=ScV/Jeg8TJzpObOL9fjcye1XGYg2YYxE4e63lPEGRNg=; h=To:From:Subject:Message-ID:Date; b=Ewl+8QyzldmPPqm3e12B1ihpIzv9YfNBD8xHJvuvjv61zD0VRAIoGeBpYPpbGDJLM gxatV48R2KfZuWxaxJpekc+oeaXGVA0jw13fxvU5BCOE/IHT5XPtyqUeYNEFzN4cpX heUdmfRQvH6J6/TwwPOSj6rk2xo9chtlB90dxU5U= Authentication-Results: smtp1p.mail.yandex.net; dkim=pass header.i=@passap.ru To: freebsd-arm@FreeBSD.org From: Boris Samorodov Subject: [odroidc1] boots only with serial console cable Message-ID: Date: Mon, 7 Aug 2017 21:38:44 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 18:38:50 -0000 Hi All, I use a fresh ARM-HEAD to boot Odroid-C1. It boots fine if a serial USB cable is attached. If I try to boot without that cable, nothing happens. The system does not even try to boot (the UFS partition remains clean after the power is switched off). The bundled Linux boots fine both with and without serial console cable attached. My boot.ini file is: --- ODROIDC-UBOOT-CONFIG # headless configuration setenv m_bpp "32" setenv hpd "0" setenv cec "0" setenv vpu "0" setenv hdmioutput "0" fatload mmc 0 0x100000 kernel.bin go 0x100000 --- I've googled this behavior, but fond nothing relevant (seems to be FreeBSD specific). PS. I don't have any HDMI/cable monitor to watch video signal at boot. Any help is appreciated. Thanks! -- WBR, bsam From owner-freebsd-arm@freebsd.org Tue Aug 8 02:22:58 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7604DDAD95 for ; Tue, 8 Aug 2017 02:22:58 +0000 (UTC) (envelope-from visteksales03@163.com) Received: from m13-96.163.com (m13-96.163.com [220.181.13.96]) by mx1.freebsd.org (Postfix) with ESMTP id E323369D0E for ; Tue, 8 Aug 2017 02:22:57 +0000 (UTC) (envelope-from visteksales03@163.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=I2yWK 0KajRmAjbirSptKvEMq1uA4AUyBMaPk3F/srwE=; b=E4UZevIDXL+/2ZXwXPUqB taHS1/yOcWWIo9VqgNwt3E8iKY2P/M5uJbemiMbsISkHJ6z7mH9kqcFED6tNeb+H QJGjnqxmdEvadUnqFVqADi68RrzDnXZDDeCg1GMGY+iU+eQcA3zwqc9kzKmp51wt hF/NBZYM56KiApkNGoI6XA= Received: from visteksales03$163.com ( [219.133.178.53] ) by ajax-webmail-wmsvr96 (Coremail) ; Tue, 8 Aug 2017 10:03:41 +0800 (CST) X-Originating-IP: [219.133.178.53] Date: Tue, 8 Aug 2017 10:03:41 +0800 (CST) From: visteksales03 To: freebsd-arm@freebsd.org Subject: New house decor and duplex wall cover plates X-Priority: 1 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20160729(86883.8884) Copyright (c) 2002-2017 www.mailtech.cn 163com X-CM-CTRLDATA: PTIKfWZvb3Rlcl9odG09NDYwOTo1Ng== MIME-Version: 1.0 Message-ID: <3a10e258.2a41.15dbf95578e.Coremail.visteksales03@163.com> X-Coremail-Locale: zh_CN X-CM-TRANSID: YMGowACH7bj+G4lZ9xl+AA--.43568W X-CM-SenderInfo: xylv3vxnvdzvrvqtqiywtou0bp/1tbiSBougFXljmOhEgABsT X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 02:22:59 -0000 SGVsbG8sCgoKSSBoYXZlIHNlbnQgeW91IG91ciBVU0Igd2FsbCBwbGF0ZSBjaGFyZ2VyIGFuZCBM RUQgbmlnaHQgbGlnaHQgd2FsbCBwbGF0ZSBpbmZvIGJlZm9yZSwgdGhpcyBwcm9kdWN0IGlzIGNv bWJpbmVkIHR3byBmdW5jdGlvbnMgaW50byBvbmUgcGxhdGVzLgoKCldlIHdpbGwgaGF2ZSBzYW1w bGVzIHJlYWR5IHRoaXMgd2VlayxwbHMgZG8gbm90IGhlc2l0YXRlIHRvIGNvbnRhY3QgZm9yIGFu eSBxdWVzdGlvbnMuCgoKLS0KQmVzdCBSZWdhcmRzClJvZ2VyLkx1byB8IFNhbGVzIG1hbmFnZXIK CgoKCiAKCgoKCgogCgoKCgoKIAoKCgoKCiAKCgoKCgogCgoKCgoKIAoKCgoKCiAKCgoKCgogCgoK CgoKIAoKCgoKCiAKCgoKCgogCgoKCgoKIAoKCgoKCiAKCgoKCgogCgoKCgoKIAoKCgoKCiAKCgoK CgogCgoKCgoKIAoKCgoKCiAKCgoKCgogCgoKCgoKIAoKCgoKCiAKCgoKCgogCgoKCgoKIAoKCgoK CiA= From owner-freebsd-arm@freebsd.org Tue Aug 8 11:22:15 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F35C8DD4EB8 for ; Tue, 8 Aug 2017 11:22:15 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B3A64810D4 for ; Tue, 8 Aug 2017 11:22:15 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.142] (helo=mjail2.freenet.de) by mout3.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.89 #1) id 1df2aT-0003i0-41 for freebsd-arm@freebsd.org; Tue, 08 Aug 2017 13:22:13 +0200 Received: from localhost ([::1]:40869 helo=mjail2.freenet.de) by mjail2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1df2aS-0001R6-VL for freebsd-arm@freebsd.org; Tue, 08 Aug 2017 13:22:13 +0200 Received: from mx8.freenet.de ([195.4.92.18]:57190) by mjail2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1df2Xw-00007m-EG for freebsd-arm@freebsd.org; Tue, 08 Aug 2017 13:19:36 +0200 Received: from p5ddd6d1c.dip0.t-ipconnect.de ([93.221.109.28]:30383 helo=freebsd-t420.fritz.box) by mx8.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (port 587) (Exim 4.89 #1) id 1df2Xw-0006EQ-68 for freebsd-arm@freebsd.org; Tue, 08 Aug 2017 13:19:36 +0200 Date: Tue, 8 Aug 2017 13:19:34 +0200 From: Manuel =?iso-8859-15?Q?St=FChn?= To: freebsd-arm@freebsd.org Subject: [BBB] kernel panic during boot Message-ID: <20170808111918.GA38273@freebsd-t420.fritz.box> Reply-To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-Originated-At: 93.221.109.28!30383 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 11:22:16 -0000 --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Hi, booting a FreeBSD CURRENT r322118 on a BBB (GENERIC-NODEBUG kernel) ends with a panic: [...] iichb0: mem 0x44e0b000-0x44e0bfff irq 17 on simplebus0 iichb0: I2C revision 4.0 FIFO size: 32 bytes iicbus0: on iichb0 panic: timed sleep before timers are working cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self() at db_trace_self [...] The complete boot log incl. backtrace is attached. Any ideas? --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="boot.log" U-Boot SPL 2017.01-rc3 (Feb 11 2017 - 00:43:55) Trying to boot from MMC1MMC partition switch failed *** Warning - MMC partition switch failed, using default environment reading u-boot.img reading u-boot.img U-Boot 2017.01-rc3 (Feb 11 2017 - 00:43:55 +0000) CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Card did not respond to voltage select! *** Warning - MMC init failed, using default environment not set. Validating first E-fuse MAC Net: cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 reading boot.scr ** Unable to read file boot.scr ** reading uEnv.txt ** Unable to read file uEnv.txt ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found FreeBSD U-Boot Loader (bin) reading ubldr.bin 237704 bytes read in 20 ms (11.3 MiB/s) ## Starting application at 0x82000000 ... Consoles: U-Boot console Compatible U-Boot API signature found @0x9df30c58 FreeBSD/armv6 U-Boot loader, Revision 1.2 (Sat Mar 11 12:11:52 CET 2017 manuel@freebsd-t420) DRAM: 512MB Card did not respond to voltage select! Card did not respond to voltage select! Card did not respond to voltage select! Number of U-Boot devices: 2 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=0 slice= partition=... good. Booting from disk0s2a: /boot/kernel/kernel data=0x813d80+0x180280 syms=[0x4+0x8c6a0+0x4+0xc9f3c] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/dtb/am335x-boneblack.dtb size=0x103f9 Loaded DTB from file 'am335x-boneblack.dtb'. Kernel entry at 0x82200100... Kernel args: (null) ARM Debug Architecture not supported KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #0 3df4ae2137c(master): Mon Aug 7 16:03:23 CEST 2017 manuel@freebsd-t420:/usr/home/manuel/devel/github/freebsd/obj/arm.armv6/usr/home/manuel/devel/github/freebsd/src/sys/GENERIC-NODEBUG arm FreeBSD clang version 5.0.0 (branches/release_50 309439) (based on LLVM 5.0.0svn) VT: init without driver. CPU: ARM Cortex-A8 r3p2 (ECO: 0x00000000) CPU Features: Thumb2, Security, VMSAv7 Optional instructions: UMULL, SMULL, SIMD(ext) LoUU:2 LoC:3 LoUIS:1 Cache level 1: 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc real memory = 536870912 (512 MB) avail memory = 511221760 (487 MB) Texas Instruments AM335x Processor, Revision ES2.1 arc4random: no preloaded entropy cache random: entropy device external interface kbd0 at kbdmux0 ofwbus0: simplebus0: on ofwbus0 simplebus1: on simplebus0 simplebus2: mem 0x210000-0x211fff on simplebus1 ti_scm0: mem 0-0x7ff on simplebus2 regfix0: on ofwbus0 clk_fixed0: on ofwbus0 ti_aintc0: mem 0x48200000-0x48200fff on simplebus0 ti_aintc0: Revision 5.0 cpulist0: on ofwbus0 cpu0: on cpulist0 pmu0: irq 0 on ofwbus0 am335x_prcm0: mem 0x200000-0x203fff on simplebus1 am335x_prcm0: Clocks: System 24.0 MHz, CPU 1000 MHz ti_pinmux0: mem 0x800-0xa37 on simplebus2 am335x_scm0: on ti_scm0 gpio0: mem 0x44e07000-0x44e07fff irq 7 on simplebus0 gpiobus0: on gpio0 gpioc0: on gpio0 gpio1: mem 0x4804c000-0x4804cfff irq 8 on simplebus0 gpiobus1: on gpio1 gpioc1: on gpio1 gpio2: mem 0x481ac000-0x481acfff irq 9 on simplebus0 gpiobus2: on gpio2 gpioc2: on gpio2 gpio3: mem 0x481ae000-0x481aefff irq 10 on simplebus0 gpiobus3: on gpio3 gpioc3: on gpio3 uart0: console (115384,n,8,1)atible)> mem 0x44e09000-0x44e0afff irq 11 on simplebus0 iichb0: mem 0x44e0b000-0x44e0bfff irq 17 on simplebus0 iichb0: I2C revision 4.0 FIFO size: 32 bytes iicbus0: on iichb0 panic: timed sleep before timers are working cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc05a1b7c lr = 0xc0061f5c (db_trace_self_wrapper+0x30) sp = 0xc0c138a8 fp = 0xc0c139c0 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc0061f5c lr = 0xc028cd18 (vpanic+0x158) sp = 0xc0c139c8 fp = 0xc0c139e8 r4 = 0x00000100 r5 = 0x00000001 r6 = 0xc06cd645 r7 = 0xc091b2c8 vpanic() at vpanic+0x158 pc = 0xc028cd18 lr = 0xc028cbc0 (vpanic) sp = 0xc0c139f0 fp = 0xc0c139f4 r4 = 0xc093ddc0 r5 = 0x00000004 r6 = 0xfffffa38 r7 = 0xc2997600 r8 = 0xfffffa3c r9 = 0xfffffa38 r10 = 0x00000001 vpanic() at vpanic pc = 0xc028cbc0 lr = 0xc02e6a80 (sleepq_timeout) sp = 0xc0c139fc fp = 0xc0c13a48 r4 = 0xc2997600 r5 = 0xfffffa3c r6 = 0xfffffa38 r7 = 0x00000001 r8 = 0xc0c139f4 r9 = 0xc028cbc0 r10 = 0xc0c139fc sleepq_timeout() at sleepq_timeout pc = 0xc02e6a80 lr = 0xc0298390 (_sleep+0x24c) sp = 0xc0c13a50 fp = 0xc0c13aa0 r4 = 0xc2997618 r5 = 0x00000000 r6 = 0xc2997600 r7 = 0xfffffa3c r8 = 0xfffffa38 r10 = 0x00000001 _sleep() at _sleep+0x24c pc = 0xc0298390 lr = 0xc063b8cc (ti_i2c_transfer+0x260) sp = 0xc0c13aa8 fp = 0xc0c13ae8 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc299760c r7 = 0x00000000 r8 = 0xc0c13afc r9 = 0xc2997600 r10 = 0x00000000 ti_i2c_transfer() at ti_i2c_transfer+0x260 pc = 0xc063b8cc lr = 0xc00847b0 (ds133x_probe+0x64) sp = 0xc0c13af0 fp = 0xc0c13b38 r4 = 0x00000002 r5 = 0x0000000f r6 = 0x000000d0 r7 = 0xc2a46800 r8 = 0x000100d0 r9 = 0xc0c13b14 r10 = 0xc2ae5b80 ds133x_probe() at ds133x_probe+0x64 pc = 0xc00847b0 lr = 0xc02c9018 (device_probe_child+0x1dc) sp = 0xc0c13b40 fp = 0xc0c13b68 r4 = 0xc2ae5b80 r5 = 0x00000000 r6 = 0xc29aa800 r7 = 0xc2a46800 r8 = 0x00000000 r9 = 0x00000000 r10 = 0xc285d280 device_probe_child() at device_probe_child+0x1dc pc = 0xc02c9018 lr = 0xc02c9d24 (device_probe+0x90) sp = 0xc0c13b70 fp = 0xc0c13b80 r4 = 0xffffffff r5 = 0xc2ae5b80 r6 = 0x00000000 r7 = 0xc06a5d7b r8 = 0xc2aa34c0 r9 = 0xc0c13ca8 r10 = 0xc07d9ed8 device_probe() at device_probe+0x90 pc = 0xc02c9d24 lr = 0xc02cb64c (bus_generic_attach+0x1c) sp = 0xc0c13b88 fp = 0xc0c13b90 r4 = 0xc2ae5b80 r5 = 0xc06e1d53 r6 = 0x00000000 r10 = 0xc07d9ed8 bus_generic_attach() at bus_generic_attach+0x1c pc = 0xc02cb64c lr = 0xc0089ee8 (ofw_iicbus_attach+0x2e4) sp = 0xc0c13b98 fp = 0xc0c13cd0 r4 = 0xc2ae5c00 r10 = 0xc07d9ed8 ofw_iicbus_attach() at ofw_iicbus_attach+0x2e4 pc = 0xc0089ee8 lr = 0xc02ca2ec (device_attach+0x4ec) sp = 0xc0c13cd8 fp = 0xc0c13d20 r4 = 0xc2ae5c00 r5 = 0xc095a270 r6 = 0xc29a3780 r7 = 0x00000000 r8 = 0xc093aa4c r9 = 0xc02ce34c r10 = 0xc2ae5c50 device_attach() at device_attach+0x4ec pc = 0xc02ca2ec lr = 0xc02cb658 (bus_generic_attach+0x28) sp = 0xc0c13d28 fp = 0xc0c13d30 r4 = 0xc2ae5c00 r5 = 0x80040006 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xc29a37d0 r9 = 0xc2997628 r10 = 0xc2997600 bus_generic_attach() at bus_generic_attach+0x28 pc = 0xc02cb658 lr = 0xc063b494 (ti_i2c_attach+0x364) sp = 0xc0c13d38 fp = 0xc0c13d78 r4 = 0xc29a3780 r10 = 0xc2997600 ti_i2c_attach() at ti_i2c_attach+0x364 pc = 0xc063b494 lr = 0xc02ca2ec (device_attach+0x4ec) sp = 0xc0c13d80 fp = 0xc0c13dc8 r4 = 0xc29a3780 r5 = 0xc095a270 r6 = 0xc29a4480 r7 = 0x00000000 r8 = 0xc093aa4c r9 = 0xc02ce34c r10 = 0xc29a37d0 device_attach() at device_attach+0x4ec pc = 0xc02ca2ec lr = 0xc02cbc98 (bus_generic_new_pass+0xf8) sp = 0xc0c13dd0 fp = 0xc0c13de8 r4 = 0xc29a3780 r5 = 0xc07d0a94 r6 = 0xc080d3f4 r7 = 0x00000000 r8 = 0xc092b3b0 r9 = 0xc07074d4 r10 = 0xc093e188 bus_generic_new_pass() at bus_generic_new_pass+0xf8 pc = 0xc02cbc98 lr = 0xc02cbc78 (bus_generic_new_pass+0xd8) sp = 0xc0c13df0 fp = 0xc0c13e08 r4 = 0xc29a4480 r5 = 0xc07d0a94 r6 = 0xc07be0a8 r7 = 0x00000000 r8 = 0xc092b3b0 r10 = 0xc093e188 bus_generic_new_pass() at bus_generic_new_pass+0xd8 pc = 0xc02cbc78 lr = 0xc02cbc78 (bus_generic_new_pass+0xd8) sp = 0xc0c13e10 fp = 0xc0c13e28 r4 = 0xc29a4800 r5 = 0xc07d0a94 r6 = 0xc07f4a60 r7 = 0x00000000 r8 = 0xc092b3b0 r10 = 0xc093e188 bus_generic_new_pass() at bus_generic_new_pass+0xd8 pc = 0xc02cbc78 lr = 0xc02cbc78 (bus_generic_new_pass+0xd8) sp = 0xc0c13e30 fp = 0xc0c13e48 r4 = 0xc29a4a80 r5 = 0xc07d0a94 r6 = 0xc092b3b0 r7 = 0x00000000 r8 = 0xc092b3b0 r10 = 0xc093e188 bus_generic_new_pass() at bus_generic_new_pass+0xd8 pc = 0xc02cbc78 lr = 0xc02cd6ec (root_bus_configure+0x80) sp = 0xc0c13e50 fp = 0xc0c13e68 r4 = 0xc07d0a94 r5 = 0xc29a4c80 r6 = 0xc092b3b0 r7 = 0xc285e060 r8 = 0xc093ebcc r10 = 0xc093e188 root_bus_configure() at root_bus_configure+0x80 pc = 0xc02cd6ec lr = 0xc0222114 (mi_startup+0xfc) sp = 0xc0c13e70 fp = 0xc0c13e90 r4 = 0xc093e284 r5 = 0x00000001 r6 = 0xc07065cc r7 = 0x00000000 r8 = 0xc093e280 r10 = 0xc093e188 mi_startup() at mi_startup+0xfc pc = 0xc0222114 lr = 0xc0000244 (btext+0x144) sp = 0xc0c13e98 fp = 0x00000000 r4 = 0xc0000378 r5 = 0xc0990000 r6 = 0x82056600 r7 = 0x00c52078 r8 = 0xc0b0e000 r9 = 0x9ff9dee0 r10 = 0x44e35000 btext() at btext+0x144 pc = 0xc0000244 lr = 0xc0000244 (btext+0x144) sp = 0xc0c13e98 fp = 0x00000000 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at $d.3: ldrb r15, [r15, r15, ror r15]! db> --XF85m9dhOBO43t/C-- From owner-freebsd-arm@freebsd.org Tue Aug 8 13:46:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 704A6DB465A for ; Tue, 8 Aug 2017 13:46:11 +0000 (UTC) (envelope-from sylvain@sylvaingarrigues.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 06F103C92 for ; Tue, 8 Aug 2017 13:46:10 +0000 (UTC) (envelope-from sylvain@sylvaingarrigues.com) Received: by mail-wm0-x243.google.com with SMTP id t138so3778523wmt.4 for ; Tue, 08 Aug 2017 06:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sylvaingarrigues-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=QWSst+xgm6j3qHFSbyEQtFLR+ZznGYh9/+DmYnDenqY=; b=EoNNgDGNN0OoIqjBEnyCY7oeGBvVAciPQ/3bLXrHNUnWwsqxpH2Q9q3PRznrDUH6+8 3baeZlTG9tbbUKmuZ0fFlQyFv6Dv4eqYi61navRfxLu14u15ku6JWBQoOktVVIJ9HevQ tbYM5mZfM2OVFAogoYk8S46UhECMYk6h9euJPmUtebxN80N62YcIN6Cw03E7tVYk7pR4 ARYeeubqHFLff4JwXu8hxHMD76pZC1dMLxdbgDCFuFxDgogCR7ZFh2h1yPSQY6wNnIer f14VhYj0vSqoUCSqyWt/3+vxslIhqYpXm5JCk+m02dljtkfTwpx5s0j6EPCVECakZ8Ro uwxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=QWSst+xgm6j3qHFSbyEQtFLR+ZznGYh9/+DmYnDenqY=; b=PWVGMYsGaJo+XW34Qz1sGeMJjr06XQvugu/IlokoYdWBmLDmRsA+82b/dt1EvCtuGO dt4uSdL7i9gV6m9hRVv3cshyQJgtuVg+BgAeRjUabU0M52unA9NdCCflsTo8lHzLSdUu slmRL7Ts+m+1qfOXpm/KVuio9VZSA6lqcBrKxNdrqhfvIKqXcAXWGQQa+HNiX8UYYjFr HkjW31PqKYrzfMoCRhREWUuNusYaupbd+YNmctnwbpsimqY3LcD8jRGpBwEOj8V1+GyG kIPv4gJXHISUWPFIdkWzm2wdy7SBtyZztz9Utt4AooDT0szicyDPhmSZMgs3OFLKrjdh s9yQ== X-Gm-Message-State: AHYfb5ia5krvZfaVPljk6ZKg0vihn/yW4ce+6RI+Ga9uHv+PvxhZXPIY Wnwn9+v5LoxlbKYFJcw= X-Received: by 10.28.166.81 with SMTP id p78mr2681694wme.147.1502199969050; Tue, 08 Aug 2017 06:46:09 -0700 (PDT) Received: from cladbsd.local (static-css-csd-147253.business.bouyguestelecom.com. [176.162.147.253]) by smtp.gmail.com with ESMTPSA id b186sm1582036wma.24.2017.08.08.06.46.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Aug 2017 06:46:08 -0700 (PDT) Date: Tue, 8 Aug 2017 15:46:06 +0200 From: Sylvain Garrigues To: freebsd-arm@freebsd.org Subject: Re: [BBB] kernel panic during boot Message-ID: <20170808133818.GA1771@cladbsd.local> References: <20170808111918.GA38273@freebsd-t420.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170808111918.GA38273@freebsd-t420.fritz.box> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 13:46:11 -0000 Hi Manuel, I may have reported the same problem in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221227 Can you try adding the following lines to GENERIC-NODEBUG: nodevice ds1307 # Dallas DS1307 RTC and compatible nodevice ds133x # Dallas DS1337, DS1338 and DS1339 RTC nodevice ds1672 # Dallas DS1672 RTC nodevice ds3231 # Dallas DS3231 RTC + temperature nodevice nxprtc # NXP RTCs: PCA/PFC212x PCA/PCF85xx nodevice s35390a # Seiko Instruments S-35390A RTC I have a suspicion one of these devices is making the kernel panic. It solved my bug. Cheers, Sylvain. On Tue, Aug 08, 2017 at 01:19:34PM +0200, Manuel Stühn wrote: > Hi, > booting a FreeBSD CURRENT r322118 on a BBB (GENERIC-NODEBUG kernel) ends > with a panic: > > [...] > iichb0: mem 0x44e0b000-0x44e0bfff irq 17 on simplebus0 > iichb0: I2C revision 4.0 FIFO size: 32 bytes > iicbus0: on iichb0 > panic: timed sleep before timers are working > cpuid = 0 > time = 1 > KDB: stack backtrace: > db_trace_self() at db_trace_self > [...] > > The complete boot log incl. backtrace is attached. > > Any ideas? > > > U-Boot SPL 2017.01-rc3 (Feb 11 2017 - 00:43:55) > Trying to boot from MMC1MMC partition switch failed > *** Warning - MMC partition switch failed, using default environment > > reading u-boot.img > reading u-boot.img > > > U-Boot 2017.01-rc3 (Feb 11 2017 - 00:43:55 +0000) > > CPU : AM335X-GP rev 2.1 > I2C: ready > DRAM: 512 MiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > Card did not respond to voltage select! > *** Warning - MMC init failed, using default environment > > not set. Validating first E-fuse MAC > Net: cpsw, usb_ether > Press SPACE to abort autoboot in 2 seconds > switch to partitions #0, OK > mmc0 is current device > SD/MMC found on device 0 > reading boot.scr > ** Unable to read file boot.scr ** > reading uEnv.txt > ** Unable to read file uEnv.txt ** > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found FreeBSD U-Boot Loader (bin) > reading ubldr.bin > 237704 bytes read in 20 ms (11.3 MiB/s) > ## Starting application at 0x82000000 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @0x9df30c58 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (Sat Mar 11 12:11:52 CET 2017 manuel@freebsd-t420) > > DRAM: 512MB > Card did not respond to voltage select! > Card did not respond to voltage select! > Card did not respond to voltage select! > Number of U-Boot devices: 2 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=0 slice= partition=... good. > Booting from disk0s2a: > /boot/kernel/kernel data=0x813d80+0x180280 syms=[0x4+0x8c6a0+0x4+0xc9f3c] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > /boot/dtb/am335x-boneblack.dtb size=0x103f9 > Loaded DTB from file 'am335x-boneblack.dtb'. > Kernel entry at 0x82200100... > Kernel args: (null) > ARM Debug Architecture not supported > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2017 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 12.0-CURRENT #0 3df4ae2137c(master): Mon Aug 7 16:03:23 CEST 2017 > manuel@freebsd-t420:/usr/home/manuel/devel/github/freebsd/obj/arm.armv6/usr/home/manuel/devel/github/freebsd/src/sys/GENERIC-NODEBUG arm > FreeBSD clang version 5.0.0 (branches/release_50 309439) (based on LLVM 5.0.0svn) > VT: init without driver. > CPU: ARM Cortex-A8 r3p2 (ECO: 0x00000000) > CPU Features: > Thumb2, Security, VMSAv7 > Optional instructions: > UMULL, SMULL, SIMD(ext) > LoUU:2 LoC:3 LoUIS:1 > Cache level 1: > 32KB/64B 4-way data cache WT WB Read-Alloc > 32KB/64B 4-way instruction cache Read-Alloc > Cache level 2: > 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc > real memory = 536870912 (512 MB) > avail memory = 511221760 (487 MB) > Texas Instruments AM335x Processor, Revision ES2.1 > arc4random: no preloaded entropy cache > random: entropy device external interface > kbd0 at kbdmux0 > ofwbus0: > simplebus0: on ofwbus0 > simplebus1: on simplebus0 > simplebus2: mem 0x210000-0x211fff on simplebus1 > ti_scm0: mem 0-0x7ff on simplebus2 > regfix0: on ofwbus0 > clk_fixed0: on ofwbus0 > ti_aintc0: mem 0x48200000-0x48200fff on simplebus0 > ti_aintc0: Revision 5.0 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > pmu0: irq 0 on ofwbus0 > am335x_prcm0: mem 0x200000-0x203fff on simplebus1 > am335x_prcm0: Clocks: System 24.0 MHz, CPU 1000 MHz > ti_pinmux0: mem 0x800-0xa37 on simplebus2 > am335x_scm0: on ti_scm0 > gpio0: mem 0x44e07000-0x44e07fff irq 7 on simplebus0 > gpiobus0: on gpio0 > gpioc0: on gpio0 > gpio1: mem 0x4804c000-0x4804cfff irq 8 on simplebus0 > gpiobus1: on gpio1 > gpioc1: on gpio1 > gpio2: mem 0x481ac000-0x481acfff irq 9 on simplebus0 > gpiobus2: on gpio2 > gpioc2: on gpio2 > gpio3: mem 0x481ae000-0x481aefff irq 10 on simplebus0 > gpiobus3: on gpio3 > gpioc3: on gpio3 > uart0: console (115384,n,8,1)atible)> mem 0x44e09000-0x44e0afff irq 11 on simplebus0 > iichb0: mem 0x44e0b000-0x44e0bfff irq 17 on simplebus0 > iichb0: I2C revision 4.0 FIFO size: 32 bytes > iicbus0: on iichb0 > panic: timed sleep before timers are working > cpuid = 0 > time = 1 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc05a1b7c lr = 0xc0061f5c (db_trace_self_wrapper+0x30) > sp = 0xc0c138a8 fp = 0xc0c139c0 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc0061f5c lr = 0xc028cd18 (vpanic+0x158) > sp = 0xc0c139c8 fp = 0xc0c139e8 > r4 = 0x00000100 r5 = 0x00000001 > r6 = 0xc06cd645 r7 = 0xc091b2c8 > vpanic() at vpanic+0x158 > pc = 0xc028cd18 lr = 0xc028cbc0 (vpanic) > sp = 0xc0c139f0 fp = 0xc0c139f4 > r4 = 0xc093ddc0 r5 = 0x00000004 > r6 = 0xfffffa38 r7 = 0xc2997600 > r8 = 0xfffffa3c r9 = 0xfffffa38 > r10 = 0x00000001 > vpanic() at vpanic > pc = 0xc028cbc0 lr = 0xc02e6a80 (sleepq_timeout) > sp = 0xc0c139fc fp = 0xc0c13a48 > r4 = 0xc2997600 r5 = 0xfffffa3c > r6 = 0xfffffa38 r7 = 0x00000001 > r8 = 0xc0c139f4 r9 = 0xc028cbc0 > r10 = 0xc0c139fc > sleepq_timeout() at sleepq_timeout > pc = 0xc02e6a80 lr = 0xc0298390 (_sleep+0x24c) > sp = 0xc0c13a50 fp = 0xc0c13aa0 > r4 = 0xc2997618 r5 = 0x00000000 > r6 = 0xc2997600 r7 = 0xfffffa3c > r8 = 0xfffffa38 r10 = 0x00000001 > _sleep() at _sleep+0x24c > pc = 0xc0298390 lr = 0xc063b8cc (ti_i2c_transfer+0x260) > sp = 0xc0c13aa8 fp = 0xc0c13ae8 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc299760c r7 = 0x00000000 > r8 = 0xc0c13afc r9 = 0xc2997600 > r10 = 0x00000000 > ti_i2c_transfer() at ti_i2c_transfer+0x260 > pc = 0xc063b8cc lr = 0xc00847b0 (ds133x_probe+0x64) > sp = 0xc0c13af0 fp = 0xc0c13b38 > r4 = 0x00000002 r5 = 0x0000000f > r6 = 0x000000d0 r7 = 0xc2a46800 > r8 = 0x000100d0 r9 = 0xc0c13b14 > r10 = 0xc2ae5b80 > ds133x_probe() at ds133x_probe+0x64 > pc = 0xc00847b0 lr = 0xc02c9018 (device_probe_child+0x1dc) > sp = 0xc0c13b40 fp = 0xc0c13b68 > r4 = 0xc2ae5b80 r5 = 0x00000000 > r6 = 0xc29aa800 r7 = 0xc2a46800 > r8 = 0x00000000 r9 = 0x00000000 > r10 = 0xc285d280 > device_probe_child() at device_probe_child+0x1dc > pc = 0xc02c9018 lr = 0xc02c9d24 (device_probe+0x90) > sp = 0xc0c13b70 fp = 0xc0c13b80 > r4 = 0xffffffff r5 = 0xc2ae5b80 > r6 = 0x00000000 r7 = 0xc06a5d7b > r8 = 0xc2aa34c0 r9 = 0xc0c13ca8 > r10 = 0xc07d9ed8 > device_probe() at device_probe+0x90 > pc = 0xc02c9d24 lr = 0xc02cb64c (bus_generic_attach+0x1c) > sp = 0xc0c13b88 fp = 0xc0c13b90 > r4 = 0xc2ae5b80 r5 = 0xc06e1d53 > r6 = 0x00000000 r10 = 0xc07d9ed8 > bus_generic_attach() at bus_generic_attach+0x1c > pc = 0xc02cb64c lr = 0xc0089ee8 (ofw_iicbus_attach+0x2e4) > sp = 0xc0c13b98 fp = 0xc0c13cd0 > r4 = 0xc2ae5c00 r10 = 0xc07d9ed8 > ofw_iicbus_attach() at ofw_iicbus_attach+0x2e4 > pc = 0xc0089ee8 lr = 0xc02ca2ec (device_attach+0x4ec) > sp = 0xc0c13cd8 fp = 0xc0c13d20 > r4 = 0xc2ae5c00 r5 = 0xc095a270 > r6 = 0xc29a3780 r7 = 0x00000000 > r8 = 0xc093aa4c r9 = 0xc02ce34c > r10 = 0xc2ae5c50 > device_attach() at device_attach+0x4ec > pc = 0xc02ca2ec lr = 0xc02cb658 (bus_generic_attach+0x28) > sp = 0xc0c13d28 fp = 0xc0c13d30 > r4 = 0xc2ae5c00 r5 = 0x80040006 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0xc29a37d0 r9 = 0xc2997628 > r10 = 0xc2997600 > bus_generic_attach() at bus_generic_attach+0x28 > pc = 0xc02cb658 lr = 0xc063b494 (ti_i2c_attach+0x364) > sp = 0xc0c13d38 fp = 0xc0c13d78 > r4 = 0xc29a3780 r10 = 0xc2997600 > ti_i2c_attach() at ti_i2c_attach+0x364 > pc = 0xc063b494 lr = 0xc02ca2ec (device_attach+0x4ec) > sp = 0xc0c13d80 fp = 0xc0c13dc8 > r4 = 0xc29a3780 r5 = 0xc095a270 > r6 = 0xc29a4480 r7 = 0x00000000 > r8 = 0xc093aa4c r9 = 0xc02ce34c > r10 = 0xc29a37d0 > device_attach() at device_attach+0x4ec > pc = 0xc02ca2ec lr = 0xc02cbc98 (bus_generic_new_pass+0xf8) > sp = 0xc0c13dd0 fp = 0xc0c13de8 > r4 = 0xc29a3780 r5 = 0xc07d0a94 > r6 = 0xc080d3f4 r7 = 0x00000000 > r8 = 0xc092b3b0 r9 = 0xc07074d4 > r10 = 0xc093e188 > bus_generic_new_pass() at bus_generic_new_pass+0xf8 > pc = 0xc02cbc98 lr = 0xc02cbc78 (bus_generic_new_pass+0xd8) > sp = 0xc0c13df0 fp = 0xc0c13e08 > r4 = 0xc29a4480 r5 = 0xc07d0a94 > r6 = 0xc07be0a8 r7 = 0x00000000 > r8 = 0xc092b3b0 r10 = 0xc093e188 > bus_generic_new_pass() at bus_generic_new_pass+0xd8 > pc = 0xc02cbc78 lr = 0xc02cbc78 (bus_generic_new_pass+0xd8) > sp = 0xc0c13e10 fp = 0xc0c13e28 > r4 = 0xc29a4800 r5 = 0xc07d0a94 > r6 = 0xc07f4a60 r7 = 0x00000000 > r8 = 0xc092b3b0 r10 = 0xc093e188 > bus_generic_new_pass() at bus_generic_new_pass+0xd8 > pc = 0xc02cbc78 lr = 0xc02cbc78 (bus_generic_new_pass+0xd8) > sp = 0xc0c13e30 fp = 0xc0c13e48 > r4 = 0xc29a4a80 r5 = 0xc07d0a94 > r6 = 0xc092b3b0 r7 = 0x00000000 > r8 = 0xc092b3b0 r10 = 0xc093e188 > bus_generic_new_pass() at bus_generic_new_pass+0xd8 > pc = 0xc02cbc78 lr = 0xc02cd6ec (root_bus_configure+0x80) > sp = 0xc0c13e50 fp = 0xc0c13e68 > r4 = 0xc07d0a94 r5 = 0xc29a4c80 > r6 = 0xc092b3b0 r7 = 0xc285e060 > r8 = 0xc093ebcc r10 = 0xc093e188 > root_bus_configure() at root_bus_configure+0x80 > pc = 0xc02cd6ec lr = 0xc0222114 (mi_startup+0xfc) > sp = 0xc0c13e70 fp = 0xc0c13e90 > r4 = 0xc093e284 r5 = 0x00000001 > r6 = 0xc07065cc r7 = 0x00000000 > r8 = 0xc093e280 r10 = 0xc093e188 > mi_startup() at mi_startup+0xfc > pc = 0xc0222114 lr = 0xc0000244 (btext+0x144) > sp = 0xc0c13e98 fp = 0x00000000 > r4 = 0xc0000378 r5 = 0xc0990000 > r6 = 0x82056600 r7 = 0x00c52078 > r8 = 0xc0b0e000 r9 = 0x9ff9dee0 > r10 = 0x44e35000 > btext() at btext+0x144 > pc = 0xc0000244 lr = 0xc0000244 (btext+0x144) > sp = 0xc0c13e98 fp = 0x00000000 > KDB: enter: panic > [ thread pid 0 tid 100000 ] > Stopped at $d.3: ldrb r15, [r15, r15, ror r15]! > db> > From owner-freebsd-arm@freebsd.org Tue Aug 8 15:15:57 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42A87DBD5E8 for ; Tue, 8 Aug 2017 15:15:57 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27A6F65D43 for ; Tue, 8 Aug 2017 15:15:56 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 361d0bb8-7c4c-11e7-a4a1-c9e62e5d9688 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 361d0bb8-7c4c-11e7-a4a1-c9e62e5d9688; Tue, 08 Aug 2017 15:14:02 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v78FElcP001397 for ; Tue, 8 Aug 2017 09:14:47 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1502205287.50720.24.camel@freebsd.org> Subject: Re: [BBB] kernel panic during boot From: Ian Lepore To: freebsd-arm@freebsd.org Date: Tue, 08 Aug 2017 09:14:47 -0600 In-Reply-To: <20170808111918.GA38273@freebsd-t420.fritz.box> References: <20170808111918.GA38273@freebsd-t420.fritz.box> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 15:15:57 -0000 On Tue, 2017-08-08 at 13:19 +0200, Manuel Stühn wrote: > Hi, > booting a FreeBSD CURRENT r322118 on a BBB (GENERIC-NODEBUG kernel) > ends  > with a panic: > > [...] > iichb0: mem 0x44e0b000-0x44e0bfff irq 17 on  > simplebus0 > iichb0: I2C revision 4.0 FIFO size: 32 bytes > iicbus0: on iichb0 > panic: timed sleep before timers are working > cpuid = 0 > time = 1 > KDB: stack backtrace: > db_trace_self() at db_trace_self > [...] > > The complete boot log incl. backtrace is attached. > > Any ideas? > Yay!  I think that may be enough of a clue for the problem reported in PR 221227 that I can start debugging it.  I'll dig into it after $work today, hopefully have some sort of fix tonight or tomorrow. -- Ian From owner-freebsd-arm@freebsd.org Wed Aug 9 00:21:44 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02809DDA3A1 for ; Wed, 9 Aug 2017 00:21:44 +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 DA0237DFEE for ; Wed, 9 Aug 2017 00:21:43 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: c09ce723-7c98-11e7-bfd0-afd4446ba3af X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id c09ce723-7c98-11e7-bfd0-afd4446ba3af; Wed, 09 Aug 2017 00:21:57 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v790LZxX002239 for ; Tue, 8 Aug 2017 18:21:35 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1502238095.50720.51.camel@freebsd.org> Subject: Re: [BBB] kernel panic during boot From: Ian Lepore To: freebsd-arm@freebsd.org Date: Tue, 08 Aug 2017 18:21:35 -0600 In-Reply-To: <20170808111918.GA38273@freebsd-t420.fritz.box> References: <20170808111918.GA38273@freebsd-t420.fritz.box> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 00:21:44 -0000 On Tue, 2017-08-08 at 13:19 +0200, Manuel Stühn wrote: > Hi, > booting a FreeBSD CURRENT r322118 on a BBB (GENERIC-NODEBUG kernel) > ends  > with a panic: > > [...] > iichb0: mem 0x44e0b000-0x44e0bfff irq 17 on  > simplebus0 > iichb0: I2C revision 4.0 FIFO size: 32 bytes > iicbus0: on iichb0 > panic: timed sleep before timers are working > cpuid = 0 > time = 1 > KDB: stack backtrace: > db_trace_self() at db_trace_self > [...] > > The complete boot log incl. backtrace is attached. > > Any ideas? It looks like we had 2 i2c rtc drivers that were misbehaving (trying to do i2c transfers before interrupts are enabled).  For now I simply removed them from the GENERIC config as a workaround (r322282).  I've ordered samples of the chips and when they arrive I'll rework the drivers to behave better. -- Ian From owner-freebsd-arm@freebsd.org Wed Aug 9 19:14:49 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F8A8DD3CD0 for ; Wed, 9 Aug 2017 19:14:49 +0000 (UTC) (envelope-from sylvain@sylvaingarrigues.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E0CFD81DEE for ; Wed, 9 Aug 2017 19:14:48 +0000 (UTC) (envelope-from sylvain@sylvaingarrigues.com) Received: by mail-wm0-x242.google.com with SMTP id d40so546925wma.3 for ; Wed, 09 Aug 2017 12:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sylvaingarrigues-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=p0oZ53NRRTng68sTbVskZlUdcVcOb6NaXhr1jj5ZE4k=; b=ubkKcrf3jDQAeEnLywfdFZGHz9DXUAq4+MxrXF15gAioX90hDelE1vN99d6j7JQ2Ka MOB/lPQGRkfufGvcEk8XnI5HzsO6YWW8kkzwGY3L8QSEwZL2bVqT8+/soQ7TA5B+i7Jt HoeEjse5XNZSifGP4dBdYFvyWQjFgRa49LadqR0jIOMlLd1ClBsKx6gAWcM55O1s5/OO CBmZlfqQiA/T8Po1oow+cMCWHWGiWbA6E/Pr20CLwPFGSv/nIoICGHuHmOq+hVb9lL+G s05GFpH/E0ztjReyJACQDXS0d8FblN93/vTaO/IlqnOiDWIZdB+9IAsWutE4q37ofAVy aRmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=p0oZ53NRRTng68sTbVskZlUdcVcOb6NaXhr1jj5ZE4k=; b=V94OJannS8zFvj8lnjpVvT8mR0rzfluBmRZSdkiRtjF+RwUTUxQ9Kdl5bOv/VVtLMJ 2nbImhTh5mhqR1VRStiPl+ruj6ckpM+Co0NxrU8UF5rUzTQRC/g42nw9iv5IJTZMZSOt 6UhXoam/waCovEP2w//RYy5sPnKRk1LNg6RK9Dc1tFGHr4QaRofEZK5DxdNUGYvQolAA EZ48fdsxL7QDd6iD/0LbROL8W7V1tX/cr+ksMIKN4jVposQG8nSYLZist7U6QV5te0jc BhSRMXfu9ysZVBUwU5RpxBzVY6no6bPgxAjagh291wzh1Pt0XIdbRQU7SUeHob0184Su r3EA== X-Gm-Message-State: AHYfb5i5BeYyBUYDVOzoIJa7wr9tHL8WUnPw20se6pkVf0OGMJbUeLeR b1LypeWBmNqt5scNHu9CoBCFG5OXuFBCV3s= X-Received: by 10.80.180.15 with SMTP id b15mr9094887edh.226.1502306086520; Wed, 09 Aug 2017 12:14:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.129.229 with HTTP; Wed, 9 Aug 2017 12:14:46 -0700 (PDT) X-Originating-IP: [82.251.149.119] From: Sylvain Garrigues Date: Wed, 9 Aug 2017 21:14:46 +0200 Message-ID: Subject: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 19:14:49 -0000 Hello, I have a kernel.bin (compiled with TARGET_ARCH=armv6) which boots perfectly on my Raspberry Pi 2 v1.1, and I don't understand why the same kernel.bin does't boot on my Raspberry Pi 3. I have same DTB and config.txt, with enable_uart=1. I can see in the kernel source code that the cortex-a53 is a listed supported processor, and the raspberry pi 3 boots by default in aarch32 mode which is compatible with code compiled for armv6. So what's wrong and what shall be done to make our armv6 kernel boot on a raspberry pi 3? Also for some time now the new raspberry pi 2 available (starting from v1.2 board revision) also have a cortex-a53 and the same soc than raspberry pi 3 so it would be great to have a working FreeBSD/armv6 image for these recent famous boards. I am interested in getting directions to make this happen (modifications needed in locore-v6.S?) Sylvain PS: If you ask why I don't use the arm64 kernel, it's because the vchiq driver does not work yet in 64 bit mode. From owner-freebsd-arm@freebsd.org Wed Aug 9 20:45:02 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0FF3DD5AF6 for ; Wed, 9 Aug 2017 20:45:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-91.reflexion.net [208.70.210.91]) (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 6973CCCA for ; Wed, 9 Aug 2017 20:45:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9870 invoked from network); 9 Aug 2017 20:38:20 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 9 Aug 2017 20:38:20 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Wed, 09 Aug 2017 16:38:20 -0400 (EDT) Received: (qmail 11630 invoked from network); 9 Aug 2017 20:38:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Aug 2017 20:38:20 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0A069EC94E0; Wed, 9 Aug 2017 13:38:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode From: Mark Millard In-Reply-To: Date: Wed, 9 Aug 2017 13:38:19 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sylvain Garrigues X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 20:45:02 -0000 On 2017-Aug-9, at 12:14 PM, Sylvain Garrigues wrote: > I have a kernel.bin (compiled with TARGET_ARCH=3Darmv6) which boots = perfectly > on my Raspberry Pi 2 v1.1, and I don't understand why the same = kernel.bin > does't boot on my Raspberry Pi 3. I have same DTB and config.txt, with > enable_uart=3D1. >=20 > I can see in the kernel source code that the cortex-a53 is a listed > supported processor, and the raspberry pi 3 boots by default in = aarch32 > mode which is compatible with code compiled for armv6. It is not so simple. Quoting: = http://infocenter.arm.com/help/index.jsp?topic=3D/com.arm.doc.dui0801a/BAB= BDFIH.html . . . "A processor based on ARMv8 can run applications built for AArch32 and AArch64 states but a change between AArch32 and AArch64 states can only happen at exception boundaries." . . . "A processor can only execute instructions from the instruction set that matches its current execution state. A processor in AArch32 state cannot execute A64 instructions, and a processor in AArch64 state cannot execute A32 or T32 instructions. You must ensure that the processor never receives instructions from the wrong instruction set for the current execution state." Also, quoting: https://community.arm.com/processors/f/discussions/2874/aarch32-in-armv8 . . . "The ARMv8 architecture says that it is IMPLEMENTATION DEFINED whether you come out of reset in AArch32 or AArch64. Which basically means it is up to the processor and chip designers. For the ARM's Cortex-A53 and Cortex-A57 processors it is controlled by a signal (AA64nAA32) which is sampled at reset. A chip designer could tie the signal to a fixed value, or provide some way to control it (e.g. a jumper)." "Assuming you came out of reset in AArch32 then you could run ARMv7 code, as ARMv8 AArch32 is an evolution of ARMv7. But you would still need to look at porting any processor/chip/board specific code, just as you would if moving between different ARMv7 parts." . . . "I would expect at least the first stage boot code (aka boot rom) to be written for AArch64 for most ARMv8-A systems. This is because it is quite simple to go from a 64-bit boot loader to a 32-bit or 64-bit OS. While it is quite tricky to get from 32-bit boot code to a 64-bit OS. Meaning a 64-bit boot loader can be more flexible. This kind of code also tends to be very chip specific anyway." Back to non-quotes. . . FreeBSD does not have the state change management for ARMv8: it only uses/has an aarch64 configuration (once FreeBSD's initial configuration is in place anyway). There is no logic for ongoing execution-state changes as far as I know. As far as I know no one has set up a boot sequence for FreeBSD to go to an aarch32 variant of FreeBSD from some earlier stage of the boot sequence. For the operating system kernel aarch32 execution state and armv7 may be related but not identical even if for user processes a kernel can be designed to support armv7 programs. Raspian runs under aarch32 on Cortex-53 by starting in aarch64 and switching to aarch32 (possibly in boot loader code) as I understand. It likely stays in the aarch32 execution state, not supporting aarch64 after switching. There are linux's that run aarch64 but allow aarch32 processes if I understand right. This is definitely more work for the operating system implementers to support the context switching and aarch32 operation. > So what's wrong and what shall be done to make our armv6 kernel boot = on a > raspberry pi 3? In the usual FreeBSD manor: if you (and/or others) do the work and donate it then FreeBSD would likely adopt it. (Background knowledge tends to limit who can do such in a timely manor.) > Also for some time now the new raspberry pi 2 available (starting from = v1.2 > board revision) also have a cortex-a53 and the same soc than raspberry = pi 3 > so it would be great to have a working FreeBSD/armv6 image for these = recent > famous boards. FreeBSD is not good at pointing out the V1.1- vs. V1.2+ issue for what is called "raspberry pi 2". Going from armv7 to armv8 with only a version number change only fits well with operating systems that have aarch32 support (or that avoid aarch64). "raspberry pi 2v8" would have been better for the wider range of operating systems so that the name was sufficient to make clear the mismatch. > I am interested in getting directions to make this happen = (modifications > needed in locore-v6.S?) To my knowledge no one has said they have ever figured this out for FreeBSD: it is a research project for whoever is interested enough to bother. > Sylvain > PS: If you ask why I don't use the arm64 kernel, it's because the = vchiq > driver does not work yet in 64 bit mode. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Aug 9 21:17:48 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10E07DD6157 for ; Wed, 9 Aug 2017 21:17:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-91.reflexion.net [208.70.210.91]) (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 C82361BDE for ; Wed, 9 Aug 2017 21:17:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7470 invoked from network); 9 Aug 2017 21:17:46 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 9 Aug 2017 21:17:46 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Wed, 09 Aug 2017 17:17:46 -0400 (EDT) Received: (qmail 16286 invoked from network); 9 Aug 2017 21:17:45 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Aug 2017 21:17:45 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1B101EC90BC; Wed, 9 Aug 2017 14:17:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode From: Mark Millard In-Reply-To: Date: Wed, 9 Aug 2017 14:17:44 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sylvain Garrigues X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 21:17:48 -0000 On 2017-Aug-9, at 1:38 PM, Mark Millard wrote: > On 2017-Aug-9, at 12:14 PM, Sylvain Garrigues wrote: >=20 >> I have a kernel.bin (compiled with TARGET_ARCH=3Darmv6) which boots = perfectly >> on my Raspberry Pi 2 v1.1, and I don't understand why the same = kernel.bin >> does't boot on my Raspberry Pi 3. I have same DTB and config.txt, = with >> enable_uart=3D1. >>=20 >> I can see in the kernel source code that the cortex-a53 is a listed >> supported processor, and the raspberry pi 3 boots by default in = aarch32 >> mode which is compatible with code compiled for armv6. >=20 > It is not so simple. Quoting: >=20 > = http://infocenter.arm.com/help/index.jsp?topic=3D/com.arm.doc.dui0801a/BAB= BDFIH.html >=20 > . . . > "A processor based on ARMv8 can run applications built > for AArch32 and AArch64 states but a change between > AArch32 and AArch64 states can only happen at exception > boundaries." > . . . > "A processor can only execute instructions from the > instruction set that matches its current execution > state. A processor in AArch32 state cannot execute > A64 instructions, and a processor in AArch64 state > cannot execute A32 or T32 instructions. You must > ensure that the processor never receives instructions > from the wrong instruction set for the current execution > state." >=20 > Also, quoting: >=20 > = https://community.arm.com/processors/f/discussions/2874/aarch32-in-armv8 >=20 > . . . > "The ARMv8 architecture says that it is IMPLEMENTATION > DEFINED whether you come out of reset in AArch32 or > AArch64. Which basically means it is up to the > processor and chip designers. For the ARM's Cortex-A53 > and Cortex-A57 processors it is controlled by a signal > (AA64nAA32) which is sampled at reset. A chip designer > could tie the signal to a fixed value, or provide some > way to control it (e.g. a jumper)." >=20 > "Assuming you came out of reset in AArch32 then you > could run ARMv7 code, as ARMv8 AArch32 is an evolution > of ARMv7. But you would still need to look at porting > any processor/chip/board specific code, just as you > would if moving between different ARMv7 parts." >=20 > . . . "I would expect at least the first stage boot > code (aka boot rom) to be written for AArch64 for most > ARMv8-A systems. This is because it is quite simple to > go from a 64-bit boot loader to a 32-bit or 64-bit OS. > While it is quite tricky to get from 32-bit boot code > to a 64-bit OS. Meaning a 64-bit boot loader can be > more flexible. This kind of code also tends to be very > chip specific anyway." >=20 > Back to non-quotes. . . >=20 > FreeBSD does not have the state change management for ARMv8: it only > uses/has an aarch64 configuration (once FreeBSD's initial = configuration > is in place anyway). There is no logic for ongoing execution-state > changes as far as I know. >=20 > As far as I know no one has set up a boot sequence for FreeBSD to > go to an aarch32 variant of FreeBSD from some earlier stage of > the boot sequence. For the operating system kernel aarch32 execution > state and armv7 may be related but not identical even if for > user processes a kernel can be designed to support armv7 programs. >=20 > Raspian runs under aarch32 on Cortex-53 by starting in aarch64 and > switching to aarch32 (possibly in boot loader code) as I understand. > It likely stays in the aarch32 execution state, not supporting > aarch64 after switching. >=20 > There are linux's that run aarch64 but allow aarch32 processes > if I understand right. This is definitely more work for the > operating system implementers to support the context > switching and aarch32 operation. >=20 >> So what's wrong and what shall be done to make our armv6 kernel boot = on a >> raspberry pi 3? >=20 > In the usual FreeBSD manor: if you (and/or others) do the work and > donate it then FreeBSD would likely adopt it. (Background knowledge > tends to limit who can do such in a timely manor.) >=20 >> Also for some time now the new raspberry pi 2 available (starting = from v1.2 >> board revision) also have a cortex-a53 and the same soc than = raspberry pi 3 >> so it would be great to have a working FreeBSD/armv6 image for these = recent >> famous boards. >=20 > FreeBSD is not good at pointing out the V1.1- vs. V1.2+ issue for > what is called "raspberry pi 2". Going from armv7 to armv8 with > only a version number change only fits well with operating systems > that have aarch32 support (or that avoid aarch64). "raspberry pi > 2v8" would have been better for the wider range of operating > systems so that the name was sufficient to make clear the mismatch. >=20 >> I am interested in getting directions to make this happen = (modifications >> needed in locore-v6.S?) >=20 > To my knowledge no one has said they have ever figured this > out for FreeBSD: it is a research project for whoever is > interested enough to bother. >=20 >> Sylvain >> PS: If you ask why I don't use the arm64 kernel, it's because the = vchiq >> driver does not work yet in 64 bit mode. Quoting some more: = ARM_v8_Instruction_Set_Architecture_%28Overview%29.pdf : "In ARMv8 AArch32 the A32, T32 and T32EE instruction sets are broadly equivalent to the instructions sets named ARM, Thumb and ThumbEE respectively in [v7A]." . . . "The following are obsoleted in ARMv8: =E2=80=A2 A32 SWP and SWPB instructions. =E2=80=A2 Jazelle (only trivial implementations are supported). =E2=80=A2 VFP short vectors and asynchronous bounces. =E2=80=A2 Fast Context Switch Extension (FCSE)." "The following are deprecated in ARMv8 and may be disabled by privileged software: =E2=80=A2 A32 and T32 CP15 barriers CP15DSB, CP15ISB and = CP15DMB. =E2=80=A2 A32 and T32 SETEND instruction. =E2=80=A2 A subset of T32 IT instruction functionality, as = described in =C2=A76.1 below. =E2=80=A2 T32EE instructions and coprocessor registers are both = deprecated and optional." "In addition some of the new functionality provided by the A64 instruction set is independent of the general purpose register width and therefore equally applicable to AArch32 state, namely: enhanced barrier types; hints; load- acquire and store-release; new IEEE 754-2008 operations; and cryptography extensions. Accordingly these new instructions are added to the A32 and T32 instruction sets by ARMv8 as described below." =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Aug 9 21:21:55 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C0B0DD63E1 for ; Wed, 9 Aug 2017 21:21:55 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3156A1F09 for ; Wed, 9 Aug 2017 21:21:55 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.141] (helo=mjail1.freenet.de) by mout0.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.89 #1) id 1dfYQK-0001ee-6o for freebsd-arm@freebsd.org; Wed, 09 Aug 2017 23:21:52 +0200 Received: from localhost ([::1]:45675 helo=mjail1.freenet.de) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1dfYGx-0000TP-69 for freebsd-arm@freebsd.org; Wed, 09 Aug 2017 23:12:11 +0200 Received: from mx11.freenet.de ([195.4.92.21]:40302) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1dfY5a-0001Wd-2X for freebsd-arm@freebsd.org; Wed, 09 Aug 2017 23:00:26 +0200 Received: from p5ddd5df9.dip0.t-ipconnect.de ([93.221.93.249]:37588 helo=freebsd-t420.fritz.box) by mx11.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (port 587) (Exim 4.89 #1) id 1dfY4X-0001VV-ME for freebsd-arm@freebsd.org; Wed, 09 Aug 2017 22:59:21 +0200 Date: Wed, 9 Aug 2017 22:59:19 +0200 From: Manuel =?iso-8859-15?Q?St=FChn?= To: freebsd-arm@freebsd.org Subject: devicetree vs. MODULE_DEPEND Message-ID: <20170809205919.GA62042@freebsd-t420.fritz.box> Reply-To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-Originated-At: 93.221.93.249!37588 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 21:21:55 -0000 Hi list, is it correct, that the sequence in the devicetree-blob defines the probing sequence without considering the MODULE_DEPEND-macro? I stumbled over an unexpected behavior during the ti_pruss-driver development. Because the ti-pruss is gone in the default devicetree, I activate it via the overlay-framework and put it to the address "/ocp/pruss@4a300000". The devicetree-blob contains the entry and the driver gets probed, but it fails to enable its clock. This is quite obvious as according to dmesg the am335x_prcm0 is probed _after_ the ti_pruss0 device. So I tried to handle this by adding an explicit dependency to ti_prcm into the ti_pruss driver like: MODULE_DEPEND(ti_pruss, ti_prcm, 1, 1, 1); It compiles cleanly, unfortunately this changes nothing. Only placing it in the devicetree after the prcm-node or loading it as a module after the OS booted up makes the device probe correctly. Any ideas? From owner-freebsd-arm@freebsd.org Wed Aug 9 21:45:54 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 599DBDD6B2F for ; Wed, 9 Aug 2017 21:45:54 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A0A92C64 for ; Wed, 9 Aug 2017 21:45:53 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.142] (helo=mjail2.freenet.de) by mout3.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.89 #1) id 1dfYnX-0002YX-9u for freebsd-arm@freebsd.org; Wed, 09 Aug 2017 23:45:51 +0200 Received: from localhost ([::1]:47045 helo=mjail2.freenet.de) by mjail2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1dfYnQ-0004kb-Er for freebsd-arm@freebsd.org; Wed, 09 Aug 2017 23:45:44 +0200 Received: from mx7.freenet.de ([195.4.92.17]:39540) by mjail2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1dfYgf-0002lo-HO for freebsd-arm@freebsd.org; Wed, 09 Aug 2017 23:38:45 +0200 Received: from p5ddd5df9.dip0.t-ipconnect.de ([93.221.93.249]:14264 helo=freebsd-t420.fritz.box) by mx7.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (port 587) (Exim 4.89 #1) id 1dfY4C-0000CR-6A for freebsd-arm@freebsd.org; Wed, 09 Aug 2017 22:59:00 +0200 Date: Wed, 9 Aug 2017 22:58:58 +0200 From: Manuel =?iso-8859-15?Q?St=FChn?= To: freebsd-arm@freebsd.org Subject: ti_pruss-driver improvement Message-ID: <20170809205858.GA55587@freebsd-t420.fritz.box> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-Originated-At: 93.221.93.249!14264 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 21:45:54 -0000 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Hi, I'm quite unsure how to proceed. I've extended the ti_pruss driver for the AM335x processor which can be found on the beaglebone black and would like to ask, what steps are necessary to get it commited to CURRENT. The diff to an actual CURRENT is attached. --EVF5PPMfhYS0aIcm Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ti_pruss.diff" diff --git a/sys/arm/ti/ti_pruss.c b/sys/arm/ti/ti_pruss.c index 8ffb9e07899..cf58095599a 100644 --- a/sys/arm/ti/ti_pruss.c +++ b/sys/arm/ti/ti_pruss.c @@ -1,5 +1,6 @@ /*- * Copyright (c) 2013 Rui Paulo + * Copyright (c) 2017 Manuel Stuehn * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -26,27 +27,32 @@ #include __FBSDID("$FreeBSD$"); +#include +#include +#include #include #include +#include #include #include #include #include #include #include +#include +#include #include #include #include #include #include #include +#include #include #include #include -#include - #include #include @@ -59,27 +65,75 @@ __FBSDID("$FreeBSD$"); #define DPRINTF(fmt, ...) #endif +static d_open_t ti_pruss_irq_open; +static d_read_t ti_pruss_irq_read; +static d_poll_t ti_pruss_irq_poll; + static device_probe_t ti_pruss_probe; static device_attach_t ti_pruss_attach; static device_detach_t ti_pruss_detach; static void ti_pruss_intr(void *); static d_open_t ti_pruss_open; static d_mmap_t ti_pruss_mmap; -static void ti_pruss_kq_read_detach(struct knote *); -static int ti_pruss_kq_read_event(struct knote *, long); -static d_kqfilter_t ti_pruss_kqfilter; +static void ti_pruss_irq_kqread_detach(struct knote *); +static int ti_pruss_irq_kqevent(struct knote *, long); +static d_kqfilter_t ti_pruss_irq_kqfilter; +static void ti_pruss_privdtor(void *data); + +#define TI_PRUSS_PRU_IRQS 2 +#define TI_PRUSS_HOST_IRQS 8 +#define TI_PRUSS_IRQS (TI_PRUSS_HOST_IRQS+TI_PRUSS_PRU_IRQS) +#define TI_PRUSS_EVENTS 64 +#define NOT_SET_STR "NONE" +#define TI_TS_ARRAY 16 + +MALLOC_DECLARE(M_PRIV_RD); +MALLOC_DEFINE(M_PRIV_RD, "read index", "per file read index of interrupts"); + +struct ctl +{ + size_t cnt; + size_t idx; +}; + +struct ts_ring_buf +{ + struct ctl ctl; + uint64_t ts[TI_TS_ARRAY]; +}; + +struct ti_pruss_irqsc +{ + struct mtx sc_mtx; + struct cdev *sc_pdev; + struct selinfo sc_selinfo; + int8_t channel; + int8_t last; + int8_t event; + bool enable; + struct ts_ring_buf tstamps; +}; -#define TI_PRUSS_IRQS 8 +static struct cdevsw ti_pruss_cdevirq = { + .d_version = D_VERSION, + .d_name = "ti_pruss_irq", + .d_open = ti_pruss_irq_open, + .d_read = ti_pruss_irq_read, + .d_poll = ti_pruss_irq_poll, + .d_kqfilter = ti_pruss_irq_kqfilter, +}; struct ti_pruss_softc { struct mtx sc_mtx; struct resource *sc_mem_res; - struct resource *sc_irq_res[TI_PRUSS_IRQS]; - void *sc_intr[TI_PRUSS_IRQS]; + struct resource *sc_irq_res[TI_PRUSS_HOST_IRQS]; + void *sc_intr[TI_PRUSS_HOST_IRQS]; + struct ti_pruss_irqsc sc_irq_devs[TI_PRUSS_IRQS]; bus_space_tag_t sc_bt; bus_space_handle_t sc_bh; struct cdev *sc_pdev; struct selinfo sc_selinfo; + bool sc_glob_irqen; }; static struct cdevsw ti_pruss_cdevsw = { @@ -87,7 +141,6 @@ static struct cdevsw ti_pruss_cdevsw = { .d_name = "ti_pruss", .d_open = ti_pruss_open, .d_mmap = ti_pruss_mmap, - .d_kqfilter = ti_pruss_kqfilter, }; static device_method_t ti_pruss_methods[] = { @@ -107,6 +160,7 @@ static driver_t ti_pruss_driver = { static devclass_t ti_pruss_devclass; DRIVER_MODULE(ti_pruss, simplebus, ti_pruss_driver, ti_pruss_devclass, 0, 0); +MODULE_DEPEND(ti_pruss, ti_prcm, 1, 1, 1); static struct resource_spec ti_pruss_irq_spec[] = { { SYS_RES_IRQ, 0, RF_ACTIVE }, @@ -119,7 +173,112 @@ static struct resource_spec ti_pruss_irq_spec[] = { { SYS_RES_IRQ, 7, RF_ACTIVE }, { -1, 0, 0 } }; -CTASSERT(TI_PRUSS_IRQS == nitems(ti_pruss_irq_spec) - 1); +CTASSERT(TI_PRUSS_HOST_IRQS == nitems(ti_pruss_irq_spec) - 1); + +static int +ti_pruss_irq_open(struct cdev *dev, int oflags, int devtype, struct thread *td) +{ + struct ctl* irqs; + struct ti_pruss_irqsc *sc; + sc = dev->si_drv1; + + irqs = malloc(sizeof(irqs), M_PRIV_RD, M_WAITOK); + if (!irqs) + return -ENOMEM; + + irqs->cnt = sc->tstamps.ctl.cnt; + irqs->idx = sc->tstamps.ctl.idx; + + return devfs_set_cdevpriv(irqs, ti_pruss_privdtor); +} + +static void +ti_pruss_privdtor(void *data) +{ + free(data, M_PRIV_RD); +} + +static int +ti_pruss_irq_poll(struct cdev *dev, int events, struct thread *td) +{ + struct ctl* irqs; + struct ti_pruss_irqsc *sc; + sc = dev->si_drv1; + + devfs_get_cdevpriv( (void**)&irqs ); + + if (events & (POLLIN | POLLRDNORM)) { + if (sc->tstamps.ctl.cnt != irqs->cnt) + return events & (POLLIN | POLLRDNORM); + else + selrecord(td, &sc->sc_selinfo); + } + return 0; +} + +static int +ti_pruss_irq_read(struct cdev *cdev, struct uio *uio, int ioflag) +{ + const size_t ts_len = sizeof(uint64_t); + struct ti_pruss_irqsc* irq; + struct ctl* priv; + int error = 0; + size_t idx; + ssize_t level; + + irq = cdev->si_drv1; + + if (uio->uio_resid < ts_len) + return (EINVAL); + + error = devfs_get_cdevpriv((void**)&priv); + if (error) + return error; + + mtx_lock(&irq->sc_mtx); + + if (irq->tstamps.ctl.cnt - priv->cnt > TI_TS_ARRAY) + { + priv->cnt = irq->tstamps.ctl.cnt; + priv->idx = irq->tstamps.ctl.idx; + mtx_unlock(&irq->sc_mtx); + return ENXIO; + } + + do + { + idx = priv->idx; + level = irq->tstamps.ctl.idx - idx; + if (level < 0) level += TI_TS_ARRAY; + + if (level == 0) + { + if (ioflag & O_NONBLOCK) + { + mtx_unlock(&irq->sc_mtx); + return EWOULDBLOCK; + } + + error = msleep(irq, &irq->sc_mtx, PCATCH | PDROP, + "pruirq", 0); + if (error) + return error; + + mtx_lock(&irq->sc_mtx); + } + }while(level == 0); + + mtx_unlock(&irq->sc_mtx); + + error = uiomove(&irq->tstamps.ts[idx], ts_len, uio); + + if( ++idx == TI_TS_ARRAY ) idx = 0; + priv->idx = idx; + + atomic_add_32(&priv->cnt, 1); + + return error; +} static struct ti_pruss_irq_arg { int irq; @@ -138,6 +297,214 @@ ti_pruss_reg_write(struct ti_pruss_softc *sc, uint32_t reg, uint32_t val) bus_space_write_4(sc->sc_bt, sc->sc_bh, reg, val); } +static __inline void +ti_pruss_interrupts_clear( struct ti_pruss_softc *sc ) +{ + /* disable global interrupt */ + ti_pruss_reg_write(sc, PRUSS_INTC_GER, 0 ); + + /* clear all events */ + ti_pruss_reg_write(sc, PRUSS_INTC_SECR0, 0xFFFFFFFF); + ti_pruss_reg_write(sc, PRUSS_INTC_SECR1, 0xFFFFFFFF); + + /* disable all host interrupts */ + ti_pruss_reg_write(sc, PRUSS_INTC_HIER, 0); +} + +static __inline int +ti_pruss_interrupts_enable(struct ti_pruss_softc *sc, int8_t irq, bool enable ) +{ + if (enable && ((sc->sc_irq_devs[irq].channel == -1) || + (sc->sc_irq_devs[irq].event== -1))) + { + device_printf( sc->sc_pdev->si_drv1, + "Interrupt chain not fully configured, not possible to enable\n" ); + return EINVAL; + } + + sc->sc_irq_devs[irq].enable = enable; + + uint32_t reg = enable ? PRUSS_INTC_HIEISR : PRUSS_INTC_HIDISR; + ti_pruss_reg_write(sc, reg, sc->sc_irq_devs[irq].channel); + + reg = enable ? PRUSS_INTC_EISR : PRUSS_INTC_EICR; + ti_pruss_reg_write(sc, reg, sc->sc_irq_devs[irq].event ); + + if( enable ) + { + sc->sc_irq_devs[irq].sc_pdev = make_dev(&ti_pruss_cdevirq, 0, UID_ROOT, GID_WHEEL, + 0600, "pruss%d.irq%d", device_get_unit(sc->sc_pdev->si_drv1), irq); + sc->sc_irq_devs[irq].sc_pdev->si_drv1 = &sc->sc_irq_devs[irq]; + + sc->sc_irq_devs[irq].tstamps.ctl.idx = 0; + } + else + { + if( sc->sc_irq_devs[irq].sc_pdev ) + { + destroy_dev(sc->sc_irq_devs[irq].sc_pdev); + sc->sc_irq_devs[irq].sc_pdev = NULL; + } + } + + return 0; +} + +static __inline void +ti_pruss_map_write(struct ti_pruss_softc *sc, uint32_t basereg, uint8_t index, uint8_t content) +{ + const size_t regadr = basereg + index & ~0x03; + const size_t bitpos = (index & 0x03) * 8; + uint32_t rmw = ti_pruss_reg_read(sc, regadr); + rmw = (rmw & ~( 0xF << bitpos)) | ( (content & 0xF) << bitpos); + ti_pruss_reg_write(sc, regadr, rmw); +} + +static int +ti_pruss_event_map( SYSCTL_HANDLER_ARGS ) +{ + struct ti_pruss_softc *sc; + const int8_t irq = arg2; + char event[sizeof(NOT_SET_STR)]; + + sc = arg1; + + if(sc->sc_irq_devs[irq].event == -1) + bcopy(NOT_SET_STR, event, sizeof(event)); + else + snprintf(event, sizeof(event), "%i", sc->sc_irq_devs[irq].event ); + + int err = sysctl_handle_string(oidp, event, sizeof(event), req); + if(err != 0) return err; + + if (req->newptr) // write event + { + if (strcmp(NOT_SET_STR, event) == 0) + { + ti_pruss_interrupts_enable(sc, irq, false); + sc->sc_irq_devs[irq].event = -1; + } + else + { + if (sc->sc_irq_devs[irq].channel == -1) + { + device_printf( sc->sc_pdev->si_drv1, + "corresponding channel not configured\n"); + return ENXIO; + } + + const int8_t channelnr = sc->sc_irq_devs[irq].channel; + const int8_t eventnr = strtol( event, NULL, 10 ); + if (eventnr > TI_PRUSS_EVENTS || eventnr < 0) + { + device_printf( sc->sc_pdev->si_drv1, + "Event number %i not valid (0 - %i)", + channelnr, TI_PRUSS_EVENTS -1); + return EINVAL; + } + + sc->sc_irq_devs[irq].channel = channelnr; + sc->sc_irq_devs[irq].event = eventnr; + + // event[nr] <= channel + ti_pruss_map_write(sc, PRUSS_INTC_CMR_BASE, + eventnr, channelnr); + } + } + return err; +} + +static int +ti_pruss_channel_map( SYSCTL_HANDLER_ARGS ) +{ + struct ti_pruss_softc *sc; + char channel[sizeof(NOT_SET_STR)]; + const int8_t irq = arg2; + + sc = arg1; + + if (sc->sc_irq_devs[irq].channel == -1) + bcopy(NOT_SET_STR, channel, sizeof(channel)); + else + snprintf(channel, sizeof(channel), "%i", sc->sc_irq_devs[irq].channel ); + + int err = sysctl_handle_string(oidp, channel, sizeof(channel), req); + if (err != 0) + return err; + + if (req->newptr) // write event + { + if (strcmp(NOT_SET_STR, channel) == 0) + { + ti_pruss_interrupts_enable(sc, irq, false); + ti_pruss_reg_write(sc, PRUSS_INTC_HIDISR, + sc->sc_irq_devs[irq].channel); + sc->sc_irq_devs[irq].channel = -1; + } + else + { + const int8_t channelnr = strtol( channel, NULL, 10 ); + if( channelnr > TI_PRUSS_IRQS || channelnr < 0 ) + { + device_printf( sc->sc_pdev->si_drv1, + "Channel number %i not valid (0 - %i)", + channelnr, TI_PRUSS_IRQS-1); + return EINVAL; + } + + sc->sc_irq_devs[irq].channel = channelnr; + sc->sc_irq_devs[irq].last = -1; + + // channel[nr] <= irqnr + ti_pruss_map_write(sc, PRUSS_INTC_HMR_BASE, + irq, channelnr); + } + } + + return err; +} + +static int +ti_pruss_interrupt_enable( SYSCTL_HANDLER_ARGS ) +{ + struct ti_pruss_softc *sc; + bool irqenable; + const int8_t irq = arg2; + + sc = arg1; + irqenable = sc->sc_irq_devs[arg2].enable; + + int err = sysctl_handle_bool(oidp, &irqenable, arg2, req); + if (err != 0) + return err; + + if (req->newptr) // write enable + return ti_pruss_interrupts_enable(sc, irq, irqenable); + + return err; +} + +static int +ti_pruss_global_interrupt_enable( SYSCTL_HANDLER_ARGS ) +{ + struct ti_pruss_softc *sc; + bool glob_irqen; + + sc = arg1; + glob_irqen = sc->sc_glob_irqen; + + int err = sysctl_handle_bool(oidp, &glob_irqen, arg2, req); + if (err != 0) + return err; + + if (req->newptr) + { + sc->sc_glob_irqen = glob_irqen; + ti_pruss_reg_write(sc, PRUSS_INTC_GER, glob_irqen); + } + + return err; +} static int ti_pruss_probe(device_t dev) { @@ -167,62 +534,127 @@ ti_pruss_attach(device_t dev) sc = device_get_softc(dev); rid = 0; mtx_init(&sc->sc_mtx, "TI PRUSS", NULL, MTX_DEF); - knlist_init_mtx(&sc->sc_selinfo.si_note, &sc->sc_mtx); sc->sc_mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, RF_ACTIVE); if (sc->sc_mem_res == NULL) { device_printf(dev, "could not allocate memory resource\n"); return (ENXIO); } + + struct sysctl_ctx_list *clist = device_get_sysctl_ctx( dev ); + if (!clist) + return (EINVAL); + + struct sysctl_oid *poid; + poid = device_get_sysctl_tree( dev ); + if (!poid) + return (EINVAL); + + sc->sc_glob_irqen = false; + struct sysctl_oid *irq_root = SYSCTL_ADD_NODE(clist, SYSCTL_CHILDREN(poid), + OID_AUTO, "irq", CTLFLAG_RD, 0, + "PRUSS Host Interrupts"); + SYSCTL_ADD_PROC(clist, SYSCTL_CHILDREN(poid), OID_AUTO, + "global_interrupt_enable", CTLFLAG_RW | CTLTYPE_U8, + sc, 0, ti_pruss_global_interrupt_enable, + "CU", "Global interrupt enable"); + sc->sc_bt = rman_get_bustag(sc->sc_mem_res); sc->sc_bh = rman_get_bushandle(sc->sc_mem_res); - if (bus_alloc_resources(dev, ti_pruss_irq_spec, sc->sc_irq_res) != 0) { + if (bus_alloc_resources(dev, ti_pruss_irq_spec, sc->sc_irq_res) != 0) + { device_printf(dev, "could not allocate interrupt resource\n"); ti_pruss_detach(dev); return (ENXIO); } - for (i = 0; i < TI_PRUSS_IRQS; i++) { - ti_pruss_irq_args[i].irq = i; - ti_pruss_irq_args[i].sc = sc; - if (bus_setup_intr(dev, sc->sc_irq_res[i], - INTR_MPSAFE | INTR_TYPE_MISC, - NULL, ti_pruss_intr, &ti_pruss_irq_args[i], - &sc->sc_intr[i]) != 0) { - device_printf(dev, - "unable to setup the interrupt handler\n"); - ti_pruss_detach(dev); - return (ENXIO); + + ti_pruss_interrupts_clear( sc ); + + for (i = 0; i < TI_PRUSS_IRQS; i++) + { + char name[8]; + snprintf(name, sizeof(name), "%i", i); + + struct sysctl_oid *irq_nodes = SYSCTL_ADD_NODE(clist, SYSCTL_CHILDREN(irq_root), + OID_AUTO, name, CTLFLAG_RD, 0, + "PRUSS Interrupts"); + SYSCTL_ADD_PROC(clist, SYSCTL_CHILDREN(irq_nodes), OID_AUTO, + "channel", CTLFLAG_RW | CTLTYPE_STRING, sc, i, ti_pruss_channel_map, + "A", "Channel attached to this irq"); + SYSCTL_ADD_PROC(clist, SYSCTL_CHILDREN(irq_nodes), OID_AUTO, + "event", CTLFLAG_RW | CTLTYPE_STRING, sc, i, ti_pruss_event_map, + "A", "Event attached to this irq"); + SYSCTL_ADD_PROC(clist, SYSCTL_CHILDREN(irq_nodes), OID_AUTO, + "enable", CTLFLAG_RW | CTLTYPE_U8, sc, i, ti_pruss_interrupt_enable, + "CU", "Enable/Disable interrupt"); + + sc->sc_irq_devs[i].event = -1; + sc->sc_irq_devs[i].channel = -1; + sc->sc_irq_devs[i].tstamps.ctl.idx = 0; + + if( i < TI_PRUSS_HOST_IRQS ) + { + ti_pruss_irq_args[i].irq = i; + ti_pruss_irq_args[i].sc = sc; + if (bus_setup_intr(dev, sc->sc_irq_res[i], + INTR_MPSAFE | INTR_TYPE_MISC, + NULL, ti_pruss_intr, &ti_pruss_irq_args[i], + &sc->sc_intr[i]) != 0) { + device_printf(dev, + "unable to setup the interrupt handler\n"); + ti_pruss_detach(dev); + + return (ENXIO); + } + mtx_init(&sc->sc_irq_devs[i].sc_mtx, "TI PRUSS IRQ", NULL, MTX_DEF); + knlist_init_mtx(&sc->sc_irq_devs[i].sc_selinfo.si_note, &sc->sc_irq_devs[i].sc_mtx); } } - if (ti_pruss_reg_read(sc, PRUSS_AM18XX_INTC) == PRUSS_AM18XX_REV) - device_printf(dev, "AM18xx PRU-ICSS\n"); - else if (ti_pruss_reg_read(sc, PRUSS_AM33XX_INTC) == PRUSS_AM33XX_REV) + + if (ti_pruss_reg_read(sc, PRUSS_AM33XX_INTC) == PRUSS_AM33XX_REV) device_printf(dev, "AM33xx PRU-ICSS\n"); sc->sc_pdev = make_dev(&ti_pruss_cdevsw, 0, UID_ROOT, GID_WHEEL, 0600, "pruss%d", device_get_unit(dev)); sc->sc_pdev->si_drv1 = dev; + /* Acc. to datasheet always write 1 to polarity registers */ + ti_pruss_reg_write(sc, PRUSS_INTC_SIPR0, 0xFFFFFFFF); + ti_pruss_reg_write(sc, PRUSS_INTC_SIPR1, 0xFFFFFFFF); + + /* Acc. to datasheet always write 0 to event type registers */ + ti_pruss_reg_write(sc, PRUSS_INTC_SITR0, 0); + ti_pruss_reg_write(sc, PRUSS_INTC_SITR1, 0); + return (0); } static int ti_pruss_detach(device_t dev) { - struct ti_pruss_softc *sc; - int i; + struct ti_pruss_softc *sc = device_get_softc(dev); + + ti_pruss_interrupts_clear( sc ); + + for (int i = 0; i < TI_PRUSS_HOST_IRQS; i++) + { + ti_pruss_interrupts_enable( sc, i, false ); - sc = device_get_softc(dev); - for (i = 0; i < TI_PRUSS_IRQS; i++) { if (sc->sc_intr[i]) bus_teardown_intr(dev, sc->sc_irq_res[i], sc->sc_intr[i]); if (sc->sc_irq_res[i]) bus_release_resource(dev, SYS_RES_IRQ, rman_get_rid(sc->sc_irq_res[i]), sc->sc_irq_res[i]); + knlist_clear(&sc->sc_irq_devs[i].sc_selinfo.si_note, 0); + mtx_lock(&sc->sc_irq_devs[i].sc_mtx); + if( !knlist_empty(&sc->sc_irq_devs[i].sc_selinfo.si_note) ) + printf("IRQ %i KQueue not empty!\n", i ); + mtx_unlock(&sc->sc_irq_devs[i].sc_mtx); + knlist_destroy(&sc->sc_irq_devs[i].sc_selinfo.si_note); + mtx_destroy(&sc->sc_irq_devs[i].sc_mtx); } - knlist_clear(&sc->sc_selinfo.si_note, 0); - knlist_destroy(&sc->sc_selinfo.si_note); + mtx_destroy(&sc->sc_mtx); if (sc->sc_mem_res) bus_release_resource(dev, SYS_RES_MEMORY, rman_get_rid(sc->sc_mem_res), @@ -240,19 +672,38 @@ ti_pruss_intr(void *arg) struct ti_pruss_irq_arg *iap = arg; struct ti_pruss_softc *sc = iap->sc; /* - * Interrupts pr1_host_intr[0:7] are mapped to + * Interrupts pr1_host_intr[0:7] are mapped to * Host-2 to Host-9 of PRU-ICSS IRQ-controller. */ - const int pru_int = iap->irq + 2; + const int pru_int = iap->irq + TI_PRUSS_PRU_IRQS; const int pru_int_mask = (1 << pru_int); + const int pru_channel = sc->sc_irq_devs[pru_int].channel; + const int pru_event = sc->sc_irq_devs[pru_channel].event; - val = ti_pruss_reg_read(sc, PRUSS_AM33XX_INTC + PRUSS_INTC_HIER); - DPRINTF("interrupt %p, %d", sc, pru_int); + val = ti_pruss_reg_read(sc, PRUSS_INTC_HIER); if (!(val & pru_int_mask)) return; - ti_pruss_reg_write(sc, PRUSS_AM33XX_INTC + PRUSS_INTC_HIDISR, - pru_int); - KNOTE_UNLOCKED(&sc->sc_selinfo.si_note, pru_int); + + ti_pruss_reg_write(sc, PRUSS_INTC_HIDISR, pru_int); + ti_pruss_reg_write(sc, PRUSS_INTC_SICR, pru_event); + ti_pruss_reg_write(sc, PRUSS_INTC_HIEISR, pru_int); + + struct ti_pruss_irqsc* irq = &sc->sc_irq_devs[pru_channel]; + size_t wr = irq->tstamps.ctl.idx; + + struct timespec ts; + nanouptime(&ts); + irq->tstamps.ts[wr] = ts.tv_sec * 1000000000 + ts.tv_nsec; + + if( ++wr == TI_TS_ARRAY ) + wr = 0; + atomic_add_32(&irq->tstamps.ctl.cnt, 1); + + irq->tstamps.ctl.idx = wr; + + KNOTE_UNLOCKED(&irq->sc_selinfo.si_note, pru_int); + wakeup(irq); + selwakeup(&irq->sc_selinfo); } static int @@ -279,12 +730,12 @@ ti_pruss_mmap(struct cdev *cdev, vm_ooffset_t offset, vm_paddr_t *paddr, static struct filterops ti_pruss_kq_read = { .f_isfd = 1, - .f_detach = ti_pruss_kq_read_detach, - .f_event = ti_pruss_kq_read_event, + .f_detach = ti_pruss_irq_kqread_detach, + .f_event = ti_pruss_irq_kqevent, }; static void -ti_pruss_kq_read_detach(struct knote *kn) +ti_pruss_irq_kqread_detach(struct knote *kn) { struct ti_pruss_softc *sc = kn->kn_hook; @@ -292,15 +743,28 @@ ti_pruss_kq_read_detach(struct knote *kn) } static int -ti_pruss_kq_read_event(struct knote *kn, long hint) +ti_pruss_irq_kqevent(struct knote *kn, long hint) { - kn->kn_data = hint; + struct ti_pruss_irqsc* irq_sc; + int notify; + + irq_sc = kn->kn_hook; + + if( hint > 0 ) + kn->kn_data = hint - 2; + + if( hint > 0 || irq_sc->last > 0 ) + notify = 1; + else + notify = 0; + + irq_sc->last = hint; - return (hint); + return (notify); } static int -ti_pruss_kqfilter(struct cdev *cdev, struct knote *kn) +ti_pruss_irq_kqfilter(struct cdev *cdev, struct knote *kn) { device_t dev = cdev->si_drv1; struct ti_pruss_softc *sc = device_get_softc(dev); diff --git a/sys/arm/ti/ti_pruss.h b/sys/arm/ti/ti_pruss.h index 4eea12e4f7d..44552a5fa53 100644 --- a/sys/arm/ti/ti_pruss.h +++ b/sys/arm/ti/ti_pruss.h @@ -1,5 +1,6 @@ /*- * Copyright (c) 2013 Rui Paulo + * Copyright (c) 2017 Manuel Stuehn * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -33,8 +34,22 @@ #define PRUSS_AM33XX_REV 0x4e82A900 #define PRUSS_AM33XX_INTC 0x20000 -#define PRUSS_INTC_HIER 0x1500 -#define PRUSS_INTC_HIDISR 0x0038 -#define PRUSS_INTC_HIPIR_BASE 0x0900 +#define PRUSS_INTC_GER (PRUSS_AM33XX_INTC + 0x0010) +#define PRUSS_INTC_SISR (PRUSS_AM33XX_INTC + 0x0020) +#define PRUSS_INTC_SICR (PRUSS_AM33XX_INTC + 0x0024) +#define PRUSS_INTC_EISR (PRUSS_AM33XX_INTC + 0x0028) +#define PRUSS_INTC_EICR (PRUSS_AM33XX_INTC + 0x002C) +#define PRUSS_INTC_HIEISR (PRUSS_AM33XX_INTC + 0x0034) +#define PRUSS_INTC_HIDISR (PRUSS_AM33XX_INTC + 0x0038) +#define PRUSS_INTC_SECR0 (PRUSS_AM33XX_INTC + 0x0280) +#define PRUSS_INTC_SECR1 (PRUSS_AM33XX_INTC + 0x0284) +#define PRUSS_INTC_CMR_BASE (PRUSS_AM33XX_INTC + 0x0400) +#define PRUSS_INTC_HMR_BASE (PRUSS_AM33XX_INTC + 0x0800) +#define PRUSS_INTC_HIPIR_BASE (PRUSS_AM33XX_INTC + 0x0900) +#define PRUSS_INTC_SIPR0 (PRUSS_AM33XX_INTC + 0x0D00) +#define PRUSS_INTC_SIPR1 (PRUSS_AM33XX_INTC + 0x0D04) +#define PRUSS_INTC_SITR0 (PRUSS_AM33XX_INTC + 0x0D80) +#define PRUSS_INTC_SITR1 (PRUSS_AM33XX_INTC + 0x0D84) +#define PRUSS_INTC_HIER (PRUSS_AM33XX_INTC + 0x1500) #endif /* _TI_PRUSS_H_ */ --EVF5PPMfhYS0aIcm-- From owner-freebsd-arm@freebsd.org Wed Aug 9 21:59:28 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8154DD6E5C for ; Wed, 9 Aug 2017 21:59:28 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4907C30FE for ; Wed, 9 Aug 2017 21:59:27 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 01f06699-7d4e-11e7-b2f5-7fbc454a3a22 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 01f06699-7d4e-11e7-b2f5-7fbc454a3a22; Wed, 09 Aug 2017 21:59:26 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v79LxLEU001973 for ; Wed, 9 Aug 2017 15:59:21 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1502315961.50720.75.camel@freebsd.org> Subject: Re: devicetree vs. MODULE_DEPEND From: Ian Lepore To: freebsd-arm@freebsd.org Date: Wed, 09 Aug 2017 15:59:21 -0600 In-Reply-To: <20170809205919.GA62042@freebsd-t420.fritz.box> References: <20170809205919.GA62042@freebsd-t420.fritz.box> Content-Type: multipart/mixed; boundary="=-5K3xDeACkttgD5cSaPTU" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 21:59:28 -0000 --=-5K3xDeACkttgD5cSaPTU Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit On Wed, 2017-08-09 at 22:59 +0200, Manuel Stühn wrote: > Hi list, > > is it correct, that the sequence in the devicetree-blob defines the  > probing sequence without considering the MODULE_DEPEND-macro? > > I stumbled over an unexpected behavior during the ti_pruss-driver  > development. Because the ti-pruss is gone in the default devicetree, > I  > activate it via the overlay-framework and put it to the address  > "/ocp/pruss@4a300000".  The devicetree-blob contains the entry and > the  > driver gets probed, but it fails to enable its clock.  > This is quite obvious as according to dmesg the am335x_prcm0 is > probed  > _after_ the ti_pruss0 device. So I tried to handle this by adding an  > explicit dependency to ti_prcm into the ti_pruss driver like:  > MODULE_DEPEND(ti_pruss, ti_prcm, 1, 1, 1); > > It compiles cleanly, unfortunately this changes nothing. Only placing > it  > in the devicetree after the prcm-node or loading it as a module > after  > the OS booted up makes the device probe correctly. > > Any ideas? MODULE_DEPEND only affects the kernel linker.  It ensures that other modules you depend on automatically get loaded along with your module. Try the attached patch to ensure that the clocks driver is loaded earlier than drivers that might rely on it. -- Ian --=-5K3xDeACkttgD5cSaPTU Content-Disposition: inline; filename="am335x_prcm.c.diff" Content-Type: text/x-patch; name="am335x_prcm.c.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: am335x/am335x_prcm.c =================================================================== --- am335x/am335x_prcm.c (revision 322019) +++ am335x/am335x_prcm.c (working copy) @@ -465,8 +465,8 @@ static driver_t am335x_prcm_driver = { static devclass_t am335x_prcm_devclass; -DRIVER_MODULE(am335x_prcm, simplebus, am335x_prcm_driver, - am335x_prcm_devclass, 0, 0); +EARLY_DRIVER_MODULE(am335x_prcm, simplebus, am335x_prcm_driver, + am335x_prcm_devclass, 0, 0, BUS_PASS_TIMER + BUS_PASS_ORDER_EARLY); MODULE_VERSION(am335x_prcm, 1); MODULE_DEPEND(am335x_prcm, ti_scm, 1, 1, 1); --=-5K3xDeACkttgD5cSaPTU-- From owner-freebsd-arm@freebsd.org Wed Aug 9 22:08:48 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 638F6DD70C4 for ; Wed, 9 Aug 2017 22:08:48 +0000 (UTC) (envelope-from sylvain@sylvaingarrigues.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 E9BEE360F for ; Wed, 9 Aug 2017 22:08:47 +0000 (UTC) (envelope-from sylvain@sylvaingarrigues.com) Received: by mail-wm0-x229.google.com with SMTP id t201so6500200wmt.1 for ; Wed, 09 Aug 2017 15:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sylvaingarrigues-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JDNBHNoAw5Y/ol23rva421Xi68IYW/yIh1ySd5eWFtw=; b=MHscqNhCMiGcVyl9MFNUNxyuUu1ZHEX9x7dd/hvukB+sF8uyzqdnuj4Fo3SmlJDkyM BiJLOKqFnZ0Rkqf2QL9y6/OzeyNmh6ob05UdTjoxOL1jdZxjcgEaPQX75NAU6USVUMn0 XS6+j5ebuDgNqaops51EuF7v8iE/Q4KC2CLDTWsKvDht7YoGatmBnwoo5ctaVy1n2M3t +wT9rHjISblLpspyI/kb0U7cELn76j0vWW9d61Wbsp2OyzFecNjucBp+Iniz6F18aqmu 1jEj/z23elyB4oiPKKyUvWexhxnopNgiD+LqPkJpKyTogbX5Oz3kAVjYzGXrrlHV7j4u PHag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JDNBHNoAw5Y/ol23rva421Xi68IYW/yIh1ySd5eWFtw=; b=SI6cMh8MMNm0k4oAC48f7TBQLPjkJoQUYy07/GCeTDDVZRUYUF5wSF8okc153Vvava 0FCNfW0Kq7lif2fi0jMFylUGEAAojO2BWWJYq/VKV4DfFZj9NKkv/+Prt+xI8qjVnJ2+ 4WVcNtRKji7fTEG2Ysp1Ly8CQom6SXM1wXlym5En1RCTRjverXVzS/avHOGXGPATicJL Xsb07TfEf1UO/l1YNpn8jHVUz8Qf5ul0X2UMSyMoPa2K/7IijDDc3a5cvS55dGcvn8x4 D6N+ukg7nTsLwIMZzPdOx92lkEi3AuCv+pZxmEjK6SrUed0vAhBp1tSNgi/SMe/ot6Mb YbPA== X-Gm-Message-State: AHYfb5jE008qYFUhiIoY+Cl6cqkdWy2W/YB+WqBSuMIx0x94X4lbhP0a 8hW4tGyj0m7KPTRitHHXY3ycUrzZ8W9HMuY= X-Received: by 10.80.188.21 with SMTP id j21mr9443007edh.139.1502316526350; Wed, 09 Aug 2017 15:08:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.129.229 with HTTP; Wed, 9 Aug 2017 15:08:45 -0700 (PDT) X-Originating-IP: [82.251.149.119] In-Reply-To: References: From: Sylvain Garrigues Date: Thu, 10 Aug 2017 00:08:45 +0200 Message-ID: Subject: Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode To: Mark Millard Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 22:08:48 -0000 Hello, 2017-08-09 22:38 GMT+02:00 Mark Millard : > > FreeBSD does not have the state change management for ARMv8: it only > uses/has an aarch64 configuration (once FreeBSD's initial configuration > is in place anyway). There is no logic for ongoing execution-state > changes as far as I know. > > As far as I know no one has set up a boot sequence for FreeBSD to > go to an aarch32 variant of FreeBSD from some earlier stage of > the boot sequence. On Raspberry Pi 3, the cortex-a53 processor starts in the aarch32 state if I'm correct, provided you don't add any arm_control=0x200 line in config.txt (no arm_control by default). > > So what's wrong and what shall be done to make our armv6 kernel boot on a > > raspberry pi 3? > > > I am interested in getting directions to make this happen (modifications > > needed in locore-v6.S?) > > To my knowledge no one has said they have ever figured this > out for FreeBSD: it is a research project for whoever is > interested enough to bother. Apparently some people may have, so did Warner say a few weeks ago: *"I've been told of people claiming to run a newer rpi2 **(v1.2 or newer) in 32-bit mode, but I've not been able to confirm the **people who are making the claims."* (see this "Creating armv7 MACHINE_ARCH" thread: https://docs.freebsd.org/cgi/getmsg.cgi?fetch=168619+0+/usr/local/www/mailindex/archive/2017/freebsd-arm/20170618.freebsd-arm ) I just plugged my serial cable and put debug char at almost every instruction in locore-v6.S to understand why we get the to raspberry pi rainbow screen of depth before entering initarm: it seems to happen just after the switch to virtual address with "ldr pc, =1f" ( https://github.com/freebsd/freebsd/blob/master/sys/arm/arm/locore-v6.S#L491). That's when I don't get any more serial output although I did setup early_putc and SOCDEV_PA & VA machinery to have early boot output - which I do get with rpi2 v1.1). I can try more debug if given instructions. Sylvain From owner-freebsd-arm@freebsd.org Wed Aug 9 22:30:40 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F057DD747F for ; Wed, 9 Aug 2017 22:30:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF2BE3E2A for ; Wed, 9 Aug 2017 22:30:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x243.google.com with SMTP id 76so616251ith.2 for ; Wed, 09 Aug 2017 15:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=julIZThG9WZLzhNFj8tMm9wARpqgtIijtS7Df2XwnK8=; b=rfGt3GOzXTMKbNamA1BcTuldHBpC/siXdw878oSxlt3faJs8d0sP9NAluHITLd+FUq kwARqi6xt3yfPOYPMiX1G+NI3r26mJqEiKDzC/QBlA23h1xdn+cjaQBoz1X7HWg0Bu+i MHD8oKW2OAYWVENsAIDLpxI6khtRGzo/qAVq6p1UyBX/JPqKBhsGa3JPeL3NyXCL9/fn 6jhOB0bf5F/2bS2j+mk4iOgzN02ZOXQsD/0yUyUBkdDZklV4jAT/BRwvQ00cF+8/IKSL mN5bwjQrnvYRAZ5gIwKVsaEpMSPaydsn2keeR3dbeIfoliCcUrtm3dTJ97oOdgDjg9va JJ8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=julIZThG9WZLzhNFj8tMm9wARpqgtIijtS7Df2XwnK8=; b=TOn+hy7FNjgx//wkIXkcpWfF34Y+dMz8gJsb1l6o/JcDkhSxHnXCw1pJyPFpuSLi40 +HzM/p8fRZ3zYJjFpLsU6eBCUTN0D4G3yIyyYRZDm3JYlNrXVDAHsLmyAIJKiqDHvUt1 Laz6NjwSedFpFekXNeUUlCrioNLui46YZTpX50u5wYl6czO9WHacstXLBYk4Hqe2Csth JxiO3C5ULUizI9qZ7RBDr0d9lN65JPT2uo7czHQ8OUdqZmveQTO8SzRhRemIqSsNpHon Ay9XmfuNUUuSnN4W2L8iZIjisCmMj3BMdnqomb2w21yIVGVuPyl/qS9v099OY4/ufqNw +QbQ== X-Gm-Message-State: AIVw112ym1ycedHM9mxvijQ1vMlm7aFPjIBATp4+lPx2kZz0lLCYUJQu CsagK1qU5HgN7H3nAy1oIjZmOr1eGhTV X-Received: by 10.36.101.2 with SMTP id u2mr8539353itb.38.1502317839151; Wed, 09 Aug 2017 15:30:39 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Wed, 9 Aug 2017 15:30:38 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:5174:9a63:631:693] In-Reply-To: References: From: Warner Losh Date: Wed, 9 Aug 2017 16:30:38 -0600 X-Google-Sender-Auth: UUyffc1Py72PR6j8IVUrhWFOBPY Message-ID: Subject: Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode To: Sylvain Garrigues Cc: Mark Millard , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 22:30:40 -0000 On Wed, Aug 9, 2017 at 4:08 PM, Sylvain Garrigues < sylvain@sylvaingarrigues.com> wrote: > > > > So what's wrong and what shall be done to make our armv6 kernel boot > on a > > > raspberry pi 3? > > > > > I am interested in getting directions to make this happen > (modifications > > > needed in locore-v6.S?) > > > > To my knowledge no one has said they have ever figured this > > out for FreeBSD: it is a research project for whoever is > > interested enough to bother. > > > Apparently some people may have, so did Warner say a few weeks ago: > *"I've been told of people claiming to run a newer rpi2 **(v1.2 or newer) > in 32-bit mode, but I've not been able to confirm the **people who are > making the claims."* > (see this "Creating armv7 MACHINE_ARCH" thread: > https://docs.freebsd.org/cgi/getmsg.cgi?fetch=168619+0+/ > usr/local/www/mailindex/archive/2017/freebsd-arm/20170618.freebsd-arm > ) > For the record, I was never able to track anybody down that had done it successfully. It was mostly "I tried the image and it didn't work" or "I had the old version that worked" when I talked to people about it. Warner From owner-freebsd-arm@freebsd.org Wed Aug 9 22:39:25 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B82ADD762C for ; Wed, 9 Aug 2017 22:39:25 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D5AF56340E; Wed, 9 Aug 2017 22:39:24 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.142] (helo=mjail2.freenet.de) by mout2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.89 #1) id 1dfZdI-0005lT-QA; Thu, 10 Aug 2017 00:39:20 +0200 Received: from localhost ([::1]:48457 helo=mjail2.freenet.de) by mjail2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1dfZbW-0005eK-4E; Thu, 10 Aug 2017 00:37:30 +0200 Received: from mx5.freenet.de ([195.4.92.15]:56564) by mjail2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1dfZY2-00011U-RQ; Thu, 10 Aug 2017 00:33:55 +0200 Received: from p5ddd5df9.dip0.t-ipconnect.de ([93.221.93.249]:16225 helo=[192.168.178.45]) by mx5.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (port 587) (Exim 4.89 #1) id 1dfZY8-0004dx-Jg; Thu, 10 Aug 2017 00:34:00 +0200 Subject: Re: devicetree vs. MODULE_DEPEND To: Ian Lepore References: <20170809205919.GA62042@freebsd-t420.fritz.box> <1502315961.50720.75.camel@freebsd.org> Cc: freebsd-arm@freebsd.org From: =?UTF-8?Q?Manuel_St=c3=bchn?= Message-ID: <4bde70fb-04e4-7d1d-ad5b-3a8f80d6993e@freenet.de> Date: Thu, 10 Aug 2017 00:33:25 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1502315961.50720.75.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originated-At: 93.221.93.249!16225 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 22:39:25 -0000 On Wed, 09 Aug 2017 15:59:21 -0600, Ian Lepore wrote > On Wed, 2017-08-09 at 22:59 +0200, Manuel Stühn wrote: >> Hi list, >> >> is it correct, that the sequence in the devicetree-blob defines the >> probing sequence without considering the MODULE_DEPEND-macro? >> >> I stumbled over an unexpected behavior during the ti_pruss-driver >> development. Because the ti-pruss is gone in the default devicetree, >> I >> activate it via the overlay-framework and put it to the address >> "/ocp/pruss@4a300000". The devicetree-blob contains the entry and >> the >> driver gets probed, but it fails to enable its clock. >> This is quite obvious as according to dmesg the am335x_prcm0 is >> probed >> _after_ the ti_pruss0 device. So I tried to handle this by adding an >> explicit dependency to ti_prcm into the ti_pruss driver like: >> MODULE_DEPEND(ti_pruss, ti_prcm, 1, 1, 1); >> >> It compiles cleanly, unfortunately this changes nothing. Only placing >> it >> in the devicetree after the prcm-node or loading it as a module >> after >> the OS booted up makes the device probe correctly. >> >> Any ideas? > > MODULE_DEPEND only affects the kernel linker. It ensures that other > modules you depend on automatically get loaded along with your module. > > Try the attached patch to ensure that the clocks driver is loaded > earlier than drivers that might rely on it. > The patch works for me, thanks for your help! From owner-freebsd-arm@freebsd.org Wed Aug 9 23:59:04 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29CAADD8855 for ; Wed, 9 Aug 2017 23:59:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-91.reflexion.net [208.70.210.91]) (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 C4C12653E9 for ; Wed, 9 Aug 2017 23:59:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18438 invoked from network); 10 Aug 2017 00:03:55 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 10 Aug 2017 00:03:55 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Wed, 09 Aug 2017 19:59:01 -0400 (EDT) Received: (qmail 30397 invoked from network); 9 Aug 2017 23:59:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Aug 2017 23:59:01 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A8D7FEC7E2B; Wed, 9 Aug 2017 16:59:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode From: Mark Millard In-Reply-To: Date: Wed, 9 Aug 2017 16:58:59 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <8910A9FB-E936-4576-97B1-B2EDCB1ED1AE@dsl-only.net> References: To: Sylvain Garrigues X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 23:59:04 -0000 On 2017-Aug-9, at 3:08 PM, Sylvain Garrigues wrote: > . . . >=20 > On Raspberry Pi 3, the cortex-a53 processor starts in the aarch32 = state if I'm correct, provided you don't add any arm_control=3D0x200 = line in config.txt (no arm_control by default). =20 >=20 > . . . [As we go beyond what I can find material to quote that directly applies take the word of folks like Ian Lepore (and others) over anything I write. (I'm lookging up things as I go.)] Seems to be as you say above. But. . . Note: aarch32 does not support armv6, just an variation on armv7. I've already listed in prior submittals some differences between aarch32 and armv7 that I found mention of. (Linux goes so far as to be configurable to partially-emulate some missing instructions, for example. FreeBSD does not.) FreeBSD for aarch64 on an rpi3 is only designed to deal with its sysutils/u-boot-rpi3 u-boot context: # more /usr/local/share/u-boot/u-boot-rpi3/config.txt=20 arm_control=3D0x200 dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don dtoverlay=3Dmmc dtoverlay=3Dpi3-disable-bt device_tree_address=3D0x100 kernel=3Du-boot.bin This indicates that this u-boot likely is in control of the aarch32 vs. aarch64 execution state that the FreeBSD kernel starts in. And u-boot-rpi3 sets up aarch64 and the aarch64 FreeBSD kernel requires that if I understand right. FreeBSD has no established u-boot variant for starting armv8 in an aarch32 execution state (or cortex-a53 specifically) and no later stages of booting that are designed to handle handoff from such a u-boot variant. At least that is my understanding. Similarly for FreeBSD armv6 (/v7) on an rpi2v1.1 (or before): # more /usr/local/share/u-boot/u-boot-rpi2/config.txt disable_commandline_tags=3D0 device_tree_address=3D0x100 device_tree=3Drpi2.dtb kernel=3Du-boot.bin This u-boot-rpi2 is not designed to deal with armv8 related early boot issues or other aarach32 vs. armv7 differences at all: It is limited to armv6/7: The design and implementation predate the v8 context and no armv8 or aarch32 support has been added as far as I know. u-boot-rpi2, later loader stages, and possibly even FreeBSD may well still use instructions (or other things) that are not supported by the aarch32 execution state on armv8 (cortex-a53). There is no u-boot variant that is explicitly for rpi2v1.2+. Overall: Supporting aarch32 is not automatic even if one starts from armv7 or specifically a cortex-a53 context unless one was lucky enough to happen to not touch or depend on any of the differences at any stage. [Note: My /usr/ports/ is at: # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 447082 Last Changed Rev: 447082 ] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Aug 10 01:46:05 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 716D0DDB8D7 for ; Thu, 10 Aug 2017 01:46:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-91.reflexion.net [208.70.210.91]) (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 34C346922F for ; Thu, 10 Aug 2017 01:46:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27380 invoked from network); 10 Aug 2017 01:46:03 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Aug 2017 01:46:03 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Wed, 09 Aug 2017 21:46:03 -0400 (EDT) Received: (qmail 17648 invoked from network); 10 Aug 2017 01:46:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Aug 2017 01:46:03 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A9C8CEC8559; Wed, 9 Aug 2017 18:46:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode From: Mark Millard In-Reply-To: <8910A9FB-E936-4576-97B1-B2EDCB1ED1AE@dsl-only.net> Date: Wed, 9 Aug 2017 18:45:58 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <8910A9FB-E936-4576-97B1-B2EDCB1ED1AE@dsl-only.net> To: Sylvain Garrigues X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 01:46:05 -0000 On 2017-Aug-9, at 4:58 PM, Mark Millard wrote: > On 2017-Aug-9, at 3:08 PM, Sylvain Garrigues wrote: >=20 >> . . . >>=20 >> On Raspberry Pi 3, the cortex-a53 processor starts in the aarch32 = state if I'm correct, provided you don't add any arm_control=3D0x200 = line in config.txt (no arm_control by default). =20 >>=20 >> . . . >=20 > [As we go beyond what I can find material to quote that > directly applies take the word of folks like Ian Lepore > (and others) over anything I write. (I'm lookging up > things as I go.)] >=20 > Seems to be as you say above. But. . . >=20 > Note: aarch32 does not support armv6, just an > variation on armv7. I've already listed in prior > submittals some differences between aarch32 and > armv7 that I found mention of. (Linux goes so far > as to be configurable to partially-emulate some > missing instructions, for example. FreeBSD does > not.) >=20 > FreeBSD for aarch64 on an rpi3 is only designed to deal > with its sysutils/u-boot-rpi3 u-boot context: >=20 > # more /usr/local/share/u-boot/u-boot-rpi3/config.txt=20 > arm_control=3D0x200 > dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don > dtoverlay=3Dmmc > dtoverlay=3Dpi3-disable-bt > device_tree_address=3D0x100 > kernel=3Du-boot.bin >=20 > This indicates that this u-boot likely is in control of > the aarch32 vs. aarch64 execution state that the FreeBSD > kernel starts in. And u-boot-rpi3 sets up aarch64 and > the aarch64 FreeBSD kernel requires that if I understand > right. >=20 > FreeBSD has no established u-boot variant for starting > armv8 in an aarch32 execution state (or cortex-a53 > specifically) and no later stages of booting that > are designed to handle handoff from such a u-boot > variant. At least that is my understanding. >=20 > Similarly for FreeBSD armv6 (/v7) on an rpi2v1.1 (or before): >=20 > # more /usr/local/share/u-boot/u-boot-rpi2/config.txt > disable_commandline_tags=3D0 > device_tree_address=3D0x100 > device_tree=3Drpi2.dtb > kernel=3Du-boot.bin >=20 > This u-boot-rpi2 is not designed to deal with > armv8 related early boot issues or other > aarach32 vs. armv7 differences at all: > It is limited to armv6/7: The design and > implementation predate the v8 context and no > armv8 or aarch32 support has been added as far > as I know. u-boot-rpi2, later loader stages, > and possibly even FreeBSD may well still use > instructions (or other things) that are not > supported by the aarch32 execution state on > armv8 (cortex-a53). >=20 > There is no u-boot variant that is explicitly > for rpi2v1.2+. >=20 >=20 > Overall: Supporting aarch32 is not automatic > even if one starts from armv7 or specifically > a cortex-a53 context unless one was lucky > enough to happen to not touch or depend on > any of the differences at any stage. > . . . I'll remind that if you try an old enough rpi2 B V1.1- raspbian image/boot files it will not boot a rpi3. At a given point they announced a file set that started to support booting the rpi3. Quoting a reference to this: https://www.raspberrypi.org/forums/viewtopic.php?t=3D58151 says: "If you use a PI3, note that it will only boot past the "rainbow screen" if you feed it the right (latest) boot files. So in case of trouble try using the latest Raspbian from the download page, or try updating your older software on an earlier PI on which it boots, with Raspbian that should work." And: https://www.raspberrypi.org/blog/raspberry-pi-3-on-sale/ says: "You=E2=80=99ll need a recent NOOBS or Raspbian image from our downloads page." So: Raspbian and its related boot files did not automatically support the rpi3 but had to be changed to do so. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Aug 10 03:13:08 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 626B0DB5B06 for ; Thu, 10 Aug 2017 03:13:08 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ECC8F6CB0E for ; Thu, 10 Aug 2017 03:13:07 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id i66so11168604wmg.0 for ; Wed, 09 Aug 2017 20:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fNCyZcNea5Ciuh/skB97Mn4EB2vJEx38YKhG8+CgesA=; b=qz3bgGCBl4zeqNT3VX112i0nbH+16ahNey/uvwM8tggedx99711sUODylIv1qaAdwR XJJXV//gNMyJdv0ZN8IEOMVg0OsfQoWGFsa9enFAZHl8MYICxdlOgZSKjedjAVZaF7mw 4OC79etXhPDLOTgJMyVbgTuVqf1HfNIq3/+Rlld1qobwED8ORAXG2FXCz0wP4OUQeaF8 rWXXpPJy9nQ7j0X2H9x03u6fuMSpxTGijyRUESmE3OVkpZjKWI0KRs2JSyG/hqME1nip mSNtTqfmM80s6HI9FeRvuPIPH/lbr2su31uvF4IyiYJiFVIeii6MhBzCWT8u7E4KbFpC ce2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fNCyZcNea5Ciuh/skB97Mn4EB2vJEx38YKhG8+CgesA=; b=E8I5QpyeH9x5mOGRtLVOytVDqJDQygiKqyXqEBkjude6kB+/8Z1FXbY8JzaBadV3vS Gwel9o74IOsgxKA4DHc6lJh2m/v+ZvMkmn9TwS6UuJzluiLs9sNH5mQvRqEjeLS+GPFw /ylytRNFW1wQLQjH1r0aLkfDTwavBbfgCzRwsoP49LLwqasdM4lepNk1LTnaFUh4wQh1 wRPnNmy8xyJOIFFAYjxLEoltf0E4F5ytSjYkB+QubFI9wTaGzOdGTGQ5wuxz9SKh9zFw DwU9nfNmURU/d+HNU123jNyCr61LsmAh7pUM4rSbCaH68kvtszDb1Oq4JC5HLZorV0VR jcyQ== X-Gm-Message-State: AHYfb5hp1sxDsrupf7rvn2/MfPPOPXG2ysvjeXGxFNtfINmArX31o8M3 iLX1i6g19lsjphdCFUyRRV68jL0tGapdEE4= X-Received: by 10.80.162.133 with SMTP id 5mr10273270edm.116.1502334785808; Wed, 09 Aug 2017 20:13:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.204.132 with HTTP; Wed, 9 Aug 2017 20:13:05 -0700 (PDT) In-Reply-To: <20170809205858.GA55587@freebsd-t420.fritz.box> References: <20170809205858.GA55587@freebsd-t420.fritz.box> From: Luiz Otavio O Souza Date: Thu, 10 Aug 2017 00:13:05 -0300 Message-ID: Subject: Re: ti_pruss-driver improvement To: =?UTF-8?Q?Manuel_St=C3=BChn?= 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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 03:13:08 -0000 On 9 August 2017 at 17:58, Manuel St=C3=BChn wrote: > Hi, > > I'm quite unsure how to proceed. I've extended the ti_pruss driver for th= e > AM335x processor which can be found on the beaglebone black and would lik= e > to ask, what steps are necessary to get it commited to CURRENT. > > The diff to an actual CURRENT is attached. Hi, Please, try to provide some guidance about how the changes can be tested or how they were tested, some description of what you are trying to accomplish and/or what issues you are trying to fix. You can also create a review in https://reviews.freebsd.org and assign it to #ARM group. Thanks, Luiz From owner-freebsd-arm@freebsd.org Thu Aug 10 10:34:38 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9BACCDCE1E2 for ; Thu, 10 Aug 2017 10:34:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-91.reflexion.net [208.70.210.91]) (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 6007B7EBCC for ; Thu, 10 Aug 2017 10:34:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11710 invoked from network); 10 Aug 2017 10:39:30 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 10 Aug 2017 10:39:30 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Thu, 10 Aug 2017 06:34:36 -0400 (EDT) Received: (qmail 8135 invoked from network); 10 Aug 2017 10:34:35 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Aug 2017 10:34:35 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 23ED7EC7B39; Thu, 10 Aug 2017 03:34:35 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320192 vs. devel/aarch64-xtoolchain-gcc and devel/aarch64-binutils (/usr/ports -r443557): "liblto_plugin.so: error loading plugin: Service unavailable" for .pico link Date: Thu, 10 Aug 2017 03:34:34 -0700 References: <15079239-4CE5-43E9-831D-994ADA0D5213@dsl-only.net> <6CAD4727-7B73-4583-B29B-7A3D071CE78D@dsl-only.net> To: freebsd-arm , FreeBSD Toolchain , FreeBSD Ports In-Reply-To: <6CAD4727-7B73-4583-B29B-7A3D071CE78D@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 10:34:38 -0000 [The problem during buildworld via aarch64-xtoolchain-gcc still occurs for -r322287 of head and -r447082 of /usr/ports. It is because of using the default static-link of devel/aarch64-binutils utilities, including /usr/local/bin/aarch64-freebsd-ld . A non-default devel/aarch64-binutils is required.] FYI: # pkg info | grep aarch64 aarch64-binutils-2.28,1 GNU binutils for AArch64 = cross-development aarch64-gcc-6.3.0 Cross GNU Compiler Collection for aarch64 aarch64-xtoolchain-gcc-0.2 Pre seeded toolchain to cross build = FreeBSD base For aarch64-binutils-2.28,1 : Configuration Options =3D=3D=3D> The following configuration options are available for = aarch64-binutils-2.28,1: RELRO=3Doff: enable -z relro in ELF linker by default STATIC=3Don: Build static executables and/or libraries =3D=3D=3D> Use 'make config' to modify these settings It build aarch64-binutils as static by default as of 2017-Feb-22: This is required to build Arm64 packages using QEMU. Poudriere copies the native ld from the host into the jail and uses that during the = build. This only works if ld is static. Reported by: krion Approved by: bapt But for aarch64-xtoolchain-gcc related use the default blocks buildworld = : building shared library libc.so.7 /usr/local/bin/aarch64-freebsd-ld: = /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so:= error loading plugin: Service unavailable collect2: error: ld returned 1 exit status *** [libc.so.7.full] Error code 1 make[4]: stopped in /usr/src/lib/libc .ERROR_TARGET=3D'libc.so.7.full' = .ERROR_META_FILE=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/sr= c/lib/libc/libc.so.7.full.meta' .MAKE.LEVEL=3D'4' MAKEFILE=3D'' . . . # file /usr/local/bin/aarch64-freebsd-ld /usr/local/bin/aarch64-freebsd-ld: ELF 64-bit LSB executable, x86-64, = version 1 (FreeBSD), statically linked, for FreeBSD 12.0 (1200036), = FreeBSD-style, not stripped # ls -lt /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/ total 43913 drwxr-xr-x 2 root wheel 3 Jun 28 17:51 plugin drwxr-xr-x 2 root wheel 6 Jun 28 17:51 install-tools -r-xr-xr-x 1 root wheel 1422072 Jun 28 17:51 lto-wrapper -r-xr-xr-x 1 root wheel 1229416 Jun 28 17:51 collect2 -r-xr-xr-x 1 root wheel 28472516 Jun 28 17:51 lto1 -r-xr-xr-x 1 root wheel 32125603 Jun 28 17:51 cc1plus -r-xr-xr-x 1 root wheel 29707472 Jun 28 17:51 cc1 lrwxr-xr-x 1 root wheel 22 Jun 28 17:51 liblto_plugin.so -> = liblto_plugin.so.0.0.0 lrwxr-xr-x 1 root wheel 22 Jun 28 17:51 liblto_plugin.so.0 -> = liblto_plugin.so.0.0.0 -rwxr-xr-x 1 root wheel 253310 Jun 28 17:51 liblto_plugin.so.0.0.0 # file /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/* /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/cc1: = ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), = dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 = (1200036), FreeBSD-style, not stripped /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/cc1plus: = ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), = dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 = (1200036), FreeBSD-style, not stripped /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/collect2: = ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), = dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 = (1200036), FreeBSD-style, not stripped /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/install-tools: = directory = /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so:= symbolic link to liblto_plugin.so.0.0.0 = /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so.= 0: symbolic link to liblto_plugin.so.0.0.0 = /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so.= 0.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), = dynamically linked, not stripped /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/lto-wrapper: = ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), = dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 = (1200036), FreeBSD-style, not stripped /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/lto1: = ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), = dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 = (1200036), FreeBSD-style, not stripped /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/plugin: = directory # ldd = /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so = /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so:= libc.so.7 =3D> /lib/libc.so.7 (0x800825000) # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 447082 Last Changed Rev: 447082 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Aug 10 11:33:43 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCAA3DCF8E6 for ; Thu, 10 Aug 2017 11:33:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-91.reflexion.net [208.70.210.91]) (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 7F326806B9 for ; Thu, 10 Aug 2017 11:33:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9987 invoked from network); 10 Aug 2017 11:38:35 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Aug 2017 11:38:35 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Thu, 10 Aug 2017 07:33:41 -0400 (EDT) Received: (qmail 1952 invoked from network); 10 Aug 2017 11:33:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Aug 2017 11:33:41 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B12EBEC94E0; Thu, 10 Aug 2017 04:33:40 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r322287 buildworld vs. devel/aarch64-xtoolchain-gcc devel/aarch64-binutils devel/aarch64-gcc: Error: selected processor does not support Message-Id: <3C8386E8-E368-4634-BF73-F8B12615CFF4@dsl-only.net> Date: Thu, 10 Aug 2017 04:33:40 -0700 To: freebsd-arm , FreeBSD Toolchain , FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 11:33:43 -0000 Attempting buildworld with devel/aarch64-xtoolchain-gcc and devel/aarch64-binutils I got: /usr/src/crypto/openssl/crypto/arm64cpuid.S: Assembler messages: /usr/src/crypto/openssl/crypto/arm64cpuid.S:23: Error: selected = processor does not support `aese v0.16b,v0.16b' /usr/src/crypto/openssl/crypto/arm64cpuid.S:30: Error: selected = processor does not support `sha1h s0,s0' /usr/src/crypto/openssl/crypto/arm64cpuid.S:37: Error: selected = processor does not support `sha256su0 v0.4s,v0.4s' /usr/src/crypto/openssl/crypto/arm64cpuid.S:43: Error: selected = processor does not support `pmull v0.1q,v0.1d,v0.1d' *** [arm64cpuid.o] Error code 1 The code in question is the probe source code: . . . .global _armv8_aes_probe .type _armv8_aes_probe,%function _armv8_aes_probe: aese v0.16b, v0.16b ret .size _armv8_aes_probe,.-_armv8_aes_probe .global _armv8_sha1_probe .type _armv8_sha1_probe,%function _armv8_sha1_probe: sha1h s0, s0 ret .size _armv8_sha1_probe,.-_armv8_sha1_probe .global _armv8_sha256_probe .type _armv8_sha256_probe,%function _armv8_sha256_probe: sha256su0 v0.4s, v0.4s ret .size _armv8_sha256_probe,.-_armv8_sha256_probe .global _armv8_pmull_probe .type _armv8_pmull_probe,%function _armv8_pmull_probe: pmull v0.1q, v0.1d, v0.1d ret .size _armv8_pmull_probe,.-_armv8_pmull_probe This source presumes that the assembler will allow the instructions via official mnemonics but /usr/local/bin/aarch64-freebsd-as does not do so here. My environment has -mcpu=3Dcortex-a53 explicitly via XCFLAGS. (It shows in reported /usr/local/bin/aarch64-unknown-freebsd12.0-gcc command for arm64cpuid.S and in the /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/cc1 command. In the /usr/local/bin/aarch64-freebsd-as command that results there is: -march=3Darmv8-a+crypto -march=3Darmv8-a+crc . See later in this submittal.) Supporting details follow for reference, with the full failure text last. # more = ~/sys_build_scripts.amd64-host/make_cortexA53_nodebug_incl_clang_xtoolchai= n-gcc-amd64-host.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_cortexA53_nodebug_incl_clang_xtoolchain-= gcc-amd64-host-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-= host" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/cortexA53_xtoolchain-gcc" \ make $* # more /root/src.configs/make.conf CFLAGS.gcc+=3D -v # more /root/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-host TO_TYPE=3Daarch64 TOOLS_TO_TYPE=3D${TO_TYPE} VERSION_CONTEXT=3D12.0 # KERNCONF=3DGENERIC-NODBG TARGET=3Darm64 .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITHOUT_LLD_BOOTSTRAP=3D WITH_LLD=3D WITH_LLD_IS_LD=3D WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a53 XCXXFLAGS+=3D -mcpu=3Dcortex-a53 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. # # # For TO (so-called "cross") stages . . . # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . . # CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc X_COMPILER_TYPE=3Dgcc CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gc= c = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g= ++ = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-c= pp .export XCC .export XCXX .export XCPP XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # # # =46rom based on clang (via system). . . # .if ${.MAKE.LEVEL} =3D=3D 0 CC=3D/usr/bin/clang CXX=3D/usr/bin/clang++ CPP=3D/usr/bin/clang-cpp .export CC .export CXX .export CPP .endif NOTE: devel/aarch64-binutils is built with the static linking disabled in order to get this far in the first place: Otherwise its ld fails for attempting a dlopen use from a statically linked program. End note. The failure text details are: --- arm64cpuid.o --- Using built-in specs. COLLECT_GCC=3D/usr/local/bin/aarch64-unknown-freebsd12.0-gcc Target: aarch64-unknown-freebsd12.0 Configured with: = /usr/obj/portswork/usr/ports/devel/aarch64-gcc/work/gcc-6.3.0/configure = --target=3Daarch64-unknown-freebsd12.0 --disable-nls = --enable-languages=3Dc,c++ --without-headers --with-gmp=3D/usr/local = --with-pkgversion=3D'FreeBSD Ports Collection for aarch64' = --with-system-zlib --with-gcc-include-dir=3D/usr/include/c++/v1/ = --with-as=3D/usr/local/bin/aarch64-freebsd-as = --with-ld=3D/usr/local/bin/aarch64-freebsd-ld --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/ --build=3Damd64-unknown-freebsd12.0 Thread model: posix gcc version 6.3.0 (FreeBSD Ports Collection for aarch64)=20 COLLECT_GCC_OPTIONS=3D'-mcpu=3Dcortex-a53' '-isystem' = '/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/include' = '-L/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/lib' = '-B' = '/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/lib' = '-B' '/usr/local/aarch64-freebsd/bin/' '-O2' '-pipe' '-I' = '/usr/src/crypto/openssl' '-D' 'TERMIOS' '-D' 'ANSI_SOURCE' '-D' = 'OPENSSL_THREADS' '-D' 'DSO_DLFCN' '-D' 'HAVE_DLFCN_H' '-D' 'L_ENDIAN' = '-D' 'SHA1_ASM' '-D' 'SHA256_ASM' '-D' 'SHA512_ASM' '-I' = '/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/secure/lib/libcry= pto' '-I' '/usr/src/crypto/openssl/crypto' '-I' = '/usr/src/crypto/openssl/crypto/asn1' '-I' = '/usr/src/crypto/openssl/crypto/evp' '-I' = '/usr/src/crypto/openssl/crypto/modes' '-std=3Dgnu90' = '-fstack-protector-strong' '-Wno-pointer-sign' '-Wno-error=3Daddress' = '-Wno-error=3Darray-bounds' '-Wno-error=3Dattributes' = '-Wno-error=3Dbool-compare' '-Wno-error=3Dcast-align' = '-Wno-error=3Dclobbered' '-Wno-error=3Denum-compare' '-Wno-error=3Dextra' = '-Wno-error=3Dinline' '-Wno-error=3Dlogical-not-parentheses' = '-Wno-error=3Dstrict-aliasing' '-Wno-error=3Duninitialized' = '-Wno-error=3Dunused-but-set-variable' '-Wno-error=3Dunused-function' = '-Wno-error=3Dunused-value' '-Wno-error=3Dstrict-overflow' = '-Wno-error=3Dmisleading-indentation' '-Wno-error=3Dnonnull-compare' = '-Wno-error=3Dshift-negative-value' '-Wno-error=3Dtautological-compare' = '-Wno-error=3Dunused-const-variable' '-v' '-march=3Darmv8-a+crypto' '-c' = '-o' 'arm64cpuid.o' '-mlittle-endian' '-mabi=3Dlp64' /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/cc1 -E = -lang-asm -quiet -v -I /usr/src/crypto/openssl -I = /usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/secure/lib/libcryp= to -I /usr/src/crypto/openssl/crypto -I = /usr/src/crypto/openssl/crypto/asn1 -I = /usr/src/crypto/openssl/crypto/evp -I = /usr/src/crypto/openssl/crypto/modes -isysroot = /usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp -D TERMIOS = -D ANSI_SOURCE -D OPENSSL_THREADS -D DSO_DLFCN -D HAVE_DLFCN_H -D = L_ENDIAN -D SHA1_ASM -D SHA256_ASM -D SHA512_ASM -isystem = /usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/include = /usr/src/crypto/openssl/crypto/arm64cpuid.S -mcpu=3Dcortex-a53 = -march=3Darmv8-a+crypto -mlittle-endian -mabi=3Dlp64 -std=3Dgnu90 = -Wno-pointer-sign -Wno-error=3Daddress -Wno-error=3Darray-bounds = -Wno-error=3Dattributes -Wno-error=3Dbool-compare -Wno-error=3Dcast-align = -Wno-error=3Dclobbered -Wno-error=3Denum-compare -Wno-error=3Dextra = -Wno-error=3Dinline -Wno-error=3Dlogical-not-parentheses = -Wno-error=3Dstrict-aliasing -Wno-error=3Duninitialized = -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-function = -Wno-error=3Dunused-value -Wno-error=3Dstrict-overflow = -Wno-error=3Dmisleading-indentation -Wno-error=3Dnonnull-compare = -Wno-error=3Dshift-negative-value -Wno-error=3Dtautological-compare = -Wno-error=3Dunused-const-variable -fstack-protector-strong -O2 = -fno-directives-only -o - | /usr/local/bin/aarch64-freebsd-as -v -I /usr/src/crypto/openssl -I = /usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/secure/lib/libcryp= to -I /usr/src/crypto/openssl/crypto -I = /usr/src/crypto/openssl/crypto/asn1 -I = /usr/src/crypto/openssl/crypto/evp -I = /usr/src/crypto/openssl/crypto/modes --traditional-format -EL = -march=3Darmv8-a+crypto -march=3Darmv8-a+crc -mabi=3Dlp64 --noexecstack = -o arm64cpuid.o GNU assembler version 2.28 (aarch64-freebsd) using BFD version (GNU = Binutils) 2.28 ignoring nonexistent directory = "/usr/local/lib/gcc/aarch64-unknown-freebsd12.0/6.3.0/../../../../aarch64-= unknown-freebsd12.0/sys-include" ignoring nonexistent directory = "/usr/local/lib/gcc/aarch64-unknown-freebsd12.0/6.3.0/../../../../aarch64-= unknown-freebsd12.0/include" #include "..." search starts here: #include <...> search starts here: /usr/src/crypto/openssl = /usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/secure/lib/libcryp= to /usr/src/crypto/openssl/crypto /usr/src/crypto/openssl/crypto/asn1 /usr/src/crypto/openssl/crypto/evp /usr/src/crypto/openssl/crypto/modes /usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/include /usr/local/lib/gcc/aarch64-unknown-freebsd12.0/6.3.0/include /usr/local/lib/gcc/aarch64-unknown-freebsd12.0/6.3.0/include-fixed End of search list. /usr/src/crypto/openssl/crypto/arm64cpuid.S: Assembler messages: /usr/src/crypto/openssl/crypto/arm64cpuid.S:23: Error: selected = processor does not support `aese v0.16b,v0.16b' /usr/src/crypto/openssl/crypto/arm64cpuid.S:30: Error: selected = processor does not support `sha1h s0,s0' /usr/src/crypto/openssl/crypto/arm64cpuid.S:37: Error: selected = processor does not support `sha256su0 v0.4s,v0.4s' /usr/src/crypto/openssl/crypto/arm64cpuid.S:43: Error: selected = processor does not support `pmull v0.1q,v0.1d,v0.1d' *** [arm64cpuid.o] Error code 1 make[4]: stopped in /usr/src/secure/lib/libcrypto .ERROR_TARGET=3D'arm64cpuid.o' = .ERROR_META_FILE=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/sr= c/secure/lib/libcrypto/arm64cpuid.o.meta' .MAKE.LEVEL=3D'4' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'/usr/local/bin/aarch64-unknown-freebsd12.0-gcc = -mcpu=3Dcortex-a53 -isystem = /usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/include = -L/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/lib = -B/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/lib = --sysroot=3D/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp = -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/crypto/openssl = -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H = -DL_ENDIAN -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM = -I/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/secure/lib/libcr= ypto -I/usr/src/crypto/openssl/crypto = -I/usr/src/crypto/openssl/crypto/asn1 = -I/usr/src/crypto/openssl/crypto/evp = -I/usr/src/crypto/openssl/crypto/modes -std=3Dgnu89 = -fstack-protector-strong -Wno-pointer-sign -Wno-error=3Daddress = -Wno-error=3Darray-bounds -Wno-error=3Dattributes = -Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered = -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict-aliasing = -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-variable = -Wno-error=3Dunused-function -Wno-error=3Dunused-value = -Wno-error=3Dstrict-overflow -Wno-error=3Dmisleading-indentation = -Wno-error=3Dnonnull-compare -Wno-error=3Dshift-negative-value = -Wno-error=3Dtautological-compare -Wno-error=3Dunused-const-variable = -v -Wa,--noexecstack -march=3Darmv8-a+crypto -c = /usr/src/crypto/openssl/crypto/arm64cpuid.S -o arm64cpuid.o; ;' .CURDIR=3D'/usr/src/secure/lib/libcrypto' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/secure/= lib/libcrypto' .TARGETS=3D'all' DESTDIR=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp' LD_LIBRARY_PATH=3D'' MACHINE=3D'arm64' MACHINE_ARCH=3D'aarch64' MAKEOBJDIRPREFIX=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' = PATH=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/legacy= /usr/sbin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/lega= cy/usr/bin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/leg= acy/bin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/sb= in:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/bin:/sb= in:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null = /usr/src/secure/lib/libcrypto/Makefile /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/secure/lib/libcrypto/Makefile.man = /usr/src/secure/lib/libcrypto/Makefile.inc = /usr/src/share/mk/bsd.endian.mk /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk = /usr/src/secure/lib/libcrypto/../Makefile.inc = /usr/src/secure/lib/libcrypto/../../Makefile.inc = /usr/src/share/mk/src.opts.mk /usr/src/lib/Makefile.inc = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/share/mk/bsd.sys.mk' .PATH=3D'. /usr/src/secure/lib/libcrypto = /usr/src/secure/lib/libcrypto/aarch64 /usr/src/crypto/openssl/crypto = /usr/src/crypto/openssl/crypto/aes /usr/src/crypto/openssl/crypto/asn1 = /usr/src/crypto/openssl/crypto/bf /usr/src/crypto/openssl/crypto/bio = /usr/src/crypto/openssl/crypto/bn /usr/src/crypto/openssl/crypto/buffer = /usr/src/crypto/openssl/crypto/camellia = /usr/src/crypto/openssl/crypto/cast /usr/src/crypto/openssl/crypto/cmac = /usr/src/crypto/openssl/crypto/cms /usr/src/crypto/openssl/crypto/comp = /usr/src/crypto/openssl/crypto/conf /usr/src/crypto/openssl/crypto/des = /usr/src/crypto/openssl/crypto/dh /usr/src/crypto/openssl/crypto/dsa = /usr/src/crypto/openssl/crypto/dso /usr/src/crypto/openssl/crypto/ec = /usr/src/crypto/openssl/crypto/ecdh /usr/src/crypto/openssl/crypto/ecdsa = /usr/src/crypto/openssl/crypto/engine /usr/src/crypto/openssl/crypto/err = /usr/src/crypto/openssl/crypto/evp /usr/src/crypto/openssl/crypto/hmac = /usr/src/crypto/openssl/crypto/idea /usr/src/crypto/openssl/crypto/krb5 = /usr/src/crypto/openssl/crypto/lhash /usr/src/crypto/openssl/crypto/md4 = /usr/src/crypto/openssl/crypto/md5 /usr/src/crypto/openssl/crypto/mdc2 = /usr/src/crypto/openssl/crypto/modes = /usr/src/crypto/openssl/crypto/objects = /usr/src/crypto/openssl/crypto/ocsp /usr/src/crypto/openssl/crypto/pem = /usr/src/crypto/openssl/crypto/pkcs12 = /usr/src/crypto/openssl/crypto/pkcs7 = /usr/src/crypto/openssl/crypto/pqueue = /usr/src/crypto/openssl/crypto/rand /usr/src/crypto/openssl/crypto/rc2 = /usr/src/crypto/openssl/crypto/rc4 /usr/src/crypto/openssl/crypto/rc5 = /usr/src/crypto/openssl/crypto/ripemd /usr/src/crypto/openssl/crypto/rsa = /usr/src/crypto/openssl/crypto/seed /usr/src/crypto/openssl/crypto/sha = /usr/src/crypto/openssl/crypto/srp /usr/src/crypto/openssl/crypto/stack = /usr/src/crypto/openssl/crypto/ts /usr/src/crypto/openssl/crypto/txt_db = /usr/src/crypto/openssl/crypto/ui = /usr/src/crypto/openssl/crypto/whrlpool = /usr/src/crypto/openssl/crypto/x509 = /usr/src/crypto/openssl/crypto/x509v3 /usr/src/secure/lib/libcrypto/man' 1 error make[4]: stopped in /usr/src/secure/lib/libcrypto .ERROR_TARGET=3D'arm64cpuid.o' = .ERROR_META_FILE=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/sr= c/secure/lib/libcrypto/arm64cpuid.o.meta' .MAKE.LEVEL=3D'4' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'/usr/local/bin/aarch64-unknown-freebsd12.0-gcc = -mcpu=3Dcortex-a53 -isystem = /usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/include = -L/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/lib = -B/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/lib = --sysroot=3D/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp = -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/crypto/openssl = -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H = -DL_ENDIAN -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM = -I/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/secure/lib/libcr= ypto -I/usr/src/crypto/openssl/crypto = -I/usr/src/crypto/openssl/crypto/asn1 = -I/usr/src/crypto/openssl/crypto/evp = -I/usr/src/crypto/openssl/crypto/modes -std=3Dgnu89 = -fstack-protector-strong -Wno-pointer-sign -Wno-error=3Daddress = -Wno-error=3Darray-bounds -Wno-error=3Dattributes = -Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered = -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict-aliasing = -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-variable = -Wno-error=3Dunused-function -Wno-error=3Dunused-value = -Wno-error=3Dstrict-overflow -Wno-error=3Dmisleading-indentation = -Wno-error=3Dnonnull-compare -Wno-error=3Dshift-negative-value = -Wno-error=3Dtautological-compare -Wno-error=3Dunused-const-variable = -v -Wa,--noexecstack -march=3Darmv8-a+crypto -c = /usr/src/crypto/openssl/crypto/arm64cpuid.S -o arm64cpuid.o; ;' .CURDIR=3D'/usr/src/secure/lib/libcrypto' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/secure/= lib/libcrypto' .TARGETS=3D'all' DESTDIR=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp' LD_LIBRARY_PATH=3D'' MACHINE=3D'arm64' MACHINE_ARCH=3D'aarch64' MAKEOBJDIRPREFIX=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' = PATH=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/legacy= /usr/sbin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/lega= cy/usr/bin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/leg= acy/bin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/sb= in:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/bin:/sb= in:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null = /usr/src/secure/lib/libcrypto/Makefile /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/secure/lib/libcrypto/Makefile.man = /usr/src/secure/lib/libcrypto/Makefile.inc = /usr/src/share/mk/bsd.endian.mk /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk = /usr/src/secure/lib/libcrypto/../Makefile.inc = /usr/src/secure/lib/libcrypto/../../Makefile.inc = /usr/src/share/mk/src.opts.mk /usr/src/lib/Makefile.inc = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/share/mk/bsd.sys.mk' .PATH=3D'. /usr/src/secure/lib/libcrypto = /usr/src/secure/lib/libcrypto/aarch64 /usr/src/crypto/openssl/crypto = /usr/src/crypto/openssl/crypto/aes /usr/src/crypto/openssl/crypto/asn1 = /usr/src/crypto/openssl/crypto/bf /usr/src/crypto/openssl/crypto/bio = /usr/src/crypto/openssl/crypto/bn /usr/src/crypto/openssl/crypto/buffer = /usr/src/crypto/openssl/crypto/camellia = /usr/src/crypto/openssl/crypto/cast /usr/src/crypto/openssl/crypto/cmac = /usr/src/crypto/openssl/crypto/cms /usr/src/crypto/openssl/crypto/comp = /usr/src/crypto/openssl/crypto/conf /usr/src/crypto/openssl/crypto/des = /usr/src/crypto/openssl/crypto/dh /usr/src/crypto/openssl/crypto/dsa = /usr/src/crypto/openssl/crypto/dso /usr/src/crypto/openssl/crypto/ec = /usr/src/crypto/openssl/crypto/ecdh /usr/src/crypto/openssl/crypto/ecdsa = /usr/src/crypto/openssl/crypto/engine /usr/src/crypto/openssl/crypto/err = /usr/src/crypto/openssl/crypto/evp /usr/src/crypto/openssl/crypto/hmac = /usr/src/crypto/openssl/crypto/idea /usr/src/crypto/openssl/crypto/krb5 = /usr/src/crypto/openssl/crypto/lhash /usr/src/crypto/openssl/crypto/md4 = /usr/src/crypto/openssl/crypto/md5 /usr/src/crypto/openssl/crypto/mdc2 = /usr/src/crypto/openssl/crypto/modes = /usr/src/crypto/openssl/crypto/objects = /usr/src/crypto/openssl/crypto/ocsp /usr/src/crypto/openssl/crypto/pem = /usr/src/crypto/openssl/crypto/pkcs12 = /usr/src/crypto/openssl/crypto/pkcs7 = /usr/src/crypto/openssl/crypto/pqueue = /usr/src/crypto/openssl/crypto/rand /usr/src/crypto/openssl/crypto/rc2 = /usr/src/crypto/openssl/crypto/rc4 /usr/src/crypto/openssl/crypto/rc5 = /usr/src/crypto/openssl/crypto/ripemd /usr/src/crypto/openssl/crypto/rsa = /usr/src/crypto/openssl/crypto/seed /usr/src/crypto/openssl/crypto/sha = /usr/src/crypto/openssl/crypto/srp /usr/src/crypto/openssl/crypto/stack = /usr/src/crypto/openssl/crypto/ts /usr/src/crypto/openssl/crypto/txt_db = /usr/src/crypto/openssl/crypto/ui = /usr/src/crypto/openssl/crypto/whrlpool = /usr/src/crypto/openssl/crypto/x509 = /usr/src/crypto/openssl/crypto/x509v3 /usr/src/secure/lib/libcrypto/man' *** [secure/lib/libcrypto__L] Error code 2 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Aug 10 13:51:06 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EAA19DD3819 for ; Thu, 10 Aug 2017 13:51:06 +0000 (UTC) (envelope-from sylvain@sylvaingarrigues.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8609D1B65 for ; Thu, 10 Aug 2017 13:51:06 +0000 (UTC) (envelope-from sylvain@sylvaingarrigues.com) Received: by mail-wm0-x22a.google.com with SMTP id i66so23134378wmg.0 for ; Thu, 10 Aug 2017 06:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sylvaingarrigues-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8dLmwmZrdFR2ruBV65scqmzcSgYpMrwtGqg3hujklVo=; b=FwnaW/6Une31TwwAEYIlTwNnOJcwz6E6KVb9uQxzcfgjVeFuj3H2NW4Yw975iQ2QV3 NYA4Q+Y9h1okGKP7iis72VBQqgNIjUlJbgxRucgMiqlF+hxmTIDKqU2wcOhkd+aw8itF UHjEUvBYVt/FzUcgPvIhypkX5jaFbTsntrY07GEtZFhyecmKrso5Hk9sPO33IRBdvXs8 v80IH+J+HVn2xU/faeHM2D2W118EFGhemO58rBaRjvGxd4uQmMQfFG7SwWumOgYHCFW9 w+5NCbv8arMrqr6/01+4XvU8+7GnQVRoTQNJ/jr76dOnulL+g4C5JRFOTqlmy6z2vjnd Ewnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8dLmwmZrdFR2ruBV65scqmzcSgYpMrwtGqg3hujklVo=; b=g9AiO/NkT5N3jSUzIkbM/wi1+Qm7jeQaAbdWxR2DQE9SvyJpw+iYEnSC2IJ3yOKTB+ 7+G8RMIgoqPNc3kn9saO1nACajayn442IeA+K3aALlqJTCRfI1yYgcFeDxE3WbxkOgJO 2+3JRWYDaekfOkdmv8WbwLwVNPU6Exxvzyq6FNSbRmhVBH2VFGURKfS9dHs39262Xmcx wSGTNe8BuRyt96OYraLwU1WA0T16ovpKVapY2NijxUflUeIrqJcrPNEQuEiGNpLNO0Ug pQzmvYF4xfhsDP+fZFkNJxAznCjVJTAYYPL+vM2xv/lcJFpwQgzoxFVRGNV+28BPQQDE gwKA== X-Gm-Message-State: AHYfb5jDKm6pBddrcqbGhgNoy4Pxrw+AZJl34nk6uEh/qwCxwWH7QL2R jcFZGsxNlsBwTgv6M08vr3mLdS+AaFMWsEA= X-Received: by 10.80.180.196 with SMTP id x4mr11962248edd.117.1502373064491; Thu, 10 Aug 2017 06:51:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.129.229 with HTTP; Thu, 10 Aug 2017 06:51:03 -0700 (PDT) X-Originating-IP: [176.162.147.253] In-Reply-To: <8910A9FB-E936-4576-97B1-B2EDCB1ED1AE@dsl-only.net> References: <8910A9FB-E936-4576-97B1-B2EDCB1ED1AE@dsl-only.net> From: Sylvain Garrigues Date: Thu, 10 Aug 2017 15:51:03 +0200 Message-ID: Subject: Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode To: Mark Millard Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 13:51:07 -0000 Hi, 2017-08-10 1:58 GMT+02:00 Mark Millard : > > Overall: Supporting aarch32 is not automatic > even if one starts from armv7 or specifically > a cortex-a53 context unless one was lucky > enough to happen to not touch or depend on > any of the differences at any stage. Thanks. I guess though that it's quite easily feasible for someone familiar with arm lower level initialization. I can see NetBSD managed to make the armv7 kernel boot on Raspberry Pi 3 with one commit: Get the RPI3 working (in aarch32 mode) by recognising Cortex A53 CPUs. - https://github.com/IIJ-NetBSD/netbsd-src/commit/00335f7adc380a125d045279c1a0f5525fb557da Same for OpenBSD folks: http://marc.info/?l=openbsd-tech&m=145692659524971&w=2 Plus FreeBSD's RPI2 armv6 kernel does boot and recognize the cortex-a53 with qemu-aarch64: qemu-system-aarch64 -M raspi2 -cpu cortex-a53 -m 1024 -smp 4 -kernel kernel.bin -serial stdio -dtb rpi2.dtb So I guess we too are really not far to boot RPI2 "armv6" kernel on raspberry pi 2 v1.2 and raspberry pi 3. I wish I could help. Sylvain From owner-freebsd-arm@freebsd.org Thu Aug 10 14:56:56 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B73AEDD4EC1 for ; Thu, 10 Aug 2017 14:56:56 +0000 (UTC) (envelope-from olavi.m.kumpulainen@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CC6563731 for ; Thu, 10 Aug 2017 14:56:56 +0000 (UTC) (envelope-from olavi.m.kumpulainen@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id m86so4619526lfi.4 for ; Thu, 10 Aug 2017 07:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=DOsTXPkAIUH4chbujY8f3HEdAzHOwMIKRkolDQnknXM=; b=nXZ/03QCOA+mO1Y283hCW+2pRe6peNxFHQ7W/6/DWOpdK+3WlL1JBk79GJgmn6D0Gz zqD2cgPOi1L44rC6lYxE5yT2LNLTM5exs7nJvt6cCNksAxMhAURIFdRA/32wRcFIEAEN QzcLSIp0Q5RdzDMiKXnU8SCiUDhM+oCXVxD6EIj2yvGkxVL5qtan14PEZePZf5IBDqnz 8jLrZXs9HOUD0GTYcq518NFqrI7B+AkUXsFgFxwBqa47D7bjWIx9JxQyYBvkpSqrGnIx VT0CdM/+N8+H0+G0VVIljbRnX6snyNHAExP3qC+S1/n5tfyNxS8LQfMWGw3IWA+Q1B07 6/cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=DOsTXPkAIUH4chbujY8f3HEdAzHOwMIKRkolDQnknXM=; b=H9EAoaRiBSEwT+HvvHYVyOZMb4OG3FZ7DfQcnLg0fH3rxIre2ButrSL+JjNBCM3SGd Q23pyCtlrhDJMbpfNwDRMK38qNthgXOdjPZQfyhdqpdLvu9vnJUILBe+cAcoqRH5GcRA xFeZzISqttGYe55LxiOzS/dNsWxpt2v6Um5dJZDMBILvoLC9FtjArwmjtFO9ny6OS21E YX39xbnbT3UMI6lnVIV95VmLMJGEsRb8zGE8DtJzWJE0CgWLQfcK8iri/VxGwciKdfmS W0nYC2oNsK6+VzPRacS/7vCVfOTkYBlEv/L0TChvn7vxMcbLg0XcIV/J0Qy/ycF879pq CGng== X-Gm-Message-State: AHYfb5iNiBHs2c8ORzjJft0t5ugH9uHWRxO0DWn0gV173Uo3lRkmEixm O7TwohcREwCt+qYy9hQ= X-Received: by 10.46.33.77 with SMTP id h74mr4123536ljh.79.1502377012611; Thu, 10 Aug 2017 07:56:52 -0700 (PDT) Received: from [192.168.1.105] (c83-251-251-174.bredband.comhem.se. [83.251.251.174]) by smtp.gmail.com with ESMTPSA id y9sm1241566lfj.74.2017.08.10.07.56.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 07:56:51 -0700 (PDT) From: Olavi Kumpulainen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Question on mountd Message-Id: Date: Thu, 10 Aug 2017 16:56:51 +0200 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 14:56:56 -0000 Hi guys, I notice that mount SIGHUP=E2=80=99s mountd every time mount succeeds. = The SIGHUP causes mountd to remount all exported directories.If this = happens while a NFS-client is accessing a share, an access error may = occur. For this purpose, there is an option to mount, -S, which locks nfsd = while the remount is executing. Can anyone of you share why mount needs to SIGHUP mountd in the first = place? It would make sense if mountd is restarted whenever /etc/exports = is modified, but always seems like overkill. /Olavi=20 From owner-freebsd-arm@freebsd.org Thu Aug 10 15:51:35 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A8D4DD6628 for ; Thu, 10 Aug 2017 15:51:35 +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 0F51B66841 for ; Thu, 10 Aug 2017 15:51:34 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: a844b002-7de3-11e7-a4a1-c9e62e5d9688 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id a844b002-7de3-11e7-a4a1-c9e62e5d9688; Thu, 10 Aug 2017 15:50:39 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v7AFpQeq003833; Thu, 10 Aug 2017 09:51:26 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1502380286.50720.97.camel@freebsd.org> Subject: Re: Question on mountd From: Ian Lepore To: Olavi Kumpulainen , freebsd-arm@freebsd.org Date: Thu, 10 Aug 2017 09:51:26 -0600 In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 15:51:35 -0000 On Thu, 2017-08-10 at 16:56 +0200, Olavi Kumpulainen wrote: > Hi guys, > > I notice that mount SIGHUP¢s mountd every time mount succeeds. The > SIGHUP causes mountd to remount all exported directories.If this > happens while a NFS-client is accessing a share, an access error may > occur. > For this purpose, there is an option to mount, -S, which locks nfsd > while the remount is executing. > > Can anyone of you share why mount needs to SIGHUP mountd in the first > place? It would make sense if mountd is restarted whenever > /etc/exports is modified, but always seems like overkill. > Based on looking through the mountd code a bit... When a new filesystem is mounted, it may be mounted on one of the mount points listed in /etc/exports.  If there was no fs mounted there previously, then mountd might have failed to set the in-kernel export attributes the last time it processed the exports file, so it has to do the processing again after the mount to update the in-kernel export data.  It would be really complex for mountd to try to figure out the minimal set of "what changed" after a mount succeeds, so it just completely reprocesses the exports file, first removing all export data from the kernel, then re- applying it all. So, all in all, I think the right fix for this is to add "mountd_flags="-r -S" to your rc.conf file (-r is a default from /etc/defaults/rc.conf). -- Ian From owner-freebsd-arm@freebsd.org Thu Aug 10 16:11:33 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C461DD6D80 for ; Thu, 10 Aug 2017 16:11:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-81.reflexion.net [208.70.210.81]) (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 E152967335 for ; Thu, 10 Aug 2017 16:11:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21197 invoked from network); 10 Aug 2017 16:06:36 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 10 Aug 2017 16:06:36 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Thu, 10 Aug 2017 12:04:51 -0400 (EDT) Received: (qmail 22729 invoked from network); 10 Aug 2017 16:04:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Aug 2017 16:04:51 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E8A13EC92A0; Thu, 10 Aug 2017 09:04:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode From: Mark Millard In-Reply-To: Date: Thu, 10 Aug 2017 09:04:50 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <11C8C2C2-02FA-493A-816E-5ED0653EAF78@dsl-only.net> References: <8910A9FB-E936-4576-97B1-B2EDCB1ED1AE@dsl-only.net> To: Sylvain Garrigues X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 16:11:33 -0000 On 2017-Aug-10, at 6:51 AM, Sylvain Garrigues wrote: > 2017-08-10 1:58 GMT+02:00 Mark Millard : >> Overall: Supporting aarch32 is not automatic >> even if one starts from armv7 or specifically >> a cortex-a53 context unless one was lucky >> enough to happen to not touch or depend on >> any of the differences at any stage. >=20 > Thanks. I guess though that it's quite easily feasible for someone = familiar with arm lower level initialization. >=20 > I can see NetBSD managed to make the armv7 kernel boot on Raspberry Pi = 3 with one commit: > Get the RPI3 working (in aarch32 mode) by recognising Cortex A53 CPUs. = - = https://github.com/IIJ-NetBSD/netbsd-src/commit/00335f7adc380a125d045279c1= a0f5525fb557da Interesting. > Same for OpenBSD folks: > http://marc.info/?l=3Dopenbsd-tech&m=3D145692659524971&w=3D2 This one (OpenBSD) says (note the "including some other (still) local diffs"): "This way, and including some other (still) local diffs, I have the brand new raspberry Pi 3 in multiuser: http://ix.io/oJV " So the reference only has some of of the code changes shown. And the boot log shows: cpu0 at mainbus0: ARM Cortex A53 rev 4 (ARMv7 core) cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled cpu0: 32KB(64b/l,2way) I-cache, 32KB(64b/l,4way) wr-back D-cache So just one cpu. But for all I know OpenBSD might not have been SMP capable on a rpi2 at the time either. The boot log also shows: gpio at bcmgpio0 not configured broadcom0: device bcmsdhc unit 0 not found So for OpenBSD the code change shown was just the start of the update as far as I can tell. > Plus FreeBSD's RPI2 armv6 kernel does boot and recognize the = cortex-a53 with qemu-aarch64: > qemu-system-aarch64 -M raspi2 -cpu cortex-a53 -m 1024 -smp 4 -kernel = kernel.bin -serial stdio -dtb rpi2.dtb Interesting. How clean is the boot log? At least for raspbian there were separate files for rpi3 when rpi3 was first supported: arch/arm/boot/dts/bcm2710-rpi-3-b.dts arch/arm/boot/dts/bcm2710.dtsi Later there was: arch/arm/boot/dts/overlays/pi3-disable-bt-overlay.dts arch/arm/boot/dts/overlays/pi3-miniuart-bt-overlay.dts arch/arm/boot/dts/overlays/pi3-disable-wifi-overlay.dts arch/arm/boot/dts/overlays/pi3-act-led-overlay.dts as well as some updates to some of those files. (I'm not sure that I found all such files that are rpi3 specific [possibly covering rpi2v1.2 as well?].) I suspect the qemu-system-aarch64 use is simulating a rpi2's details as listed in rpi2.dtb instead of the rpi3's details. (But using a cortex-a53 CPU model.) There may well be work in supporting the rpi3's details in the kernel and/or boot loading stages for all I know. What happens if a rpi3 dtb file is used instead of rpi2.dtb ? > So I guess we too are really not far to boot RPI2 "armv6" kernel on = raspberry pi 2 v1.2 and raspberry pi 3. > I wish I could help. Since I'm finding these things as I go I've no clue what I've not found. So I can not tell how close to correct you are. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Aug 10 17:32:03 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3415FDD86F3 for ; Thu, 10 Aug 2017 17:32:03 +0000 (UTC) (envelope-from olavi.m.kumpulainen@gmail.com) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A8AB46A896; Thu, 10 Aug 2017 17:32:02 +0000 (UTC) (envelope-from olavi.m.kumpulainen@gmail.com) Received: by mail-lf0-x243.google.com with SMTP id o85so930542lff.1; Thu, 10 Aug 2017 10:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HWInlbhySIMZUpxlKqYQpGdFtY68md5K5nQhRT9A6Eg=; b=S03EqsM1mfIrFeaZ4f6sB+kmnqtI3fL+OROsAOa+oGqLd3KWYTJzWOujGgzabN9H2a X+tnCde9qeRQmTAlZwjWPaEjeT4lS1ydbZQdrSJNMHIfDxIm8J5lwztoMa6/XyoCysEi i52Nwd8xv6Yu4b0wll/wTX3YGsuF/3hEG2/XioEkE4OJYNkqnC6gvHPwgx19tf/Y54Bo 47aKuEytLjhAQ2q6s4ZrQVWNA+KkIsfP0kyR4Cf/kInNpsv9hBIPxQwrs7G7EdkcdIjT 4O83Fp0yrO+n8tbo8zMNVp00vPiq3ExANLqAfovqkyl6EEbpfEwZQBG2pg6AGY6tcueh 3Vaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HWInlbhySIMZUpxlKqYQpGdFtY68md5K5nQhRT9A6Eg=; b=jUOLff3lwHfQf6lbArCTnSqIsQIllpCH20PhXrLUWkave3PvKqK7eKdfK151S9/Y4S 8DU7FOhI6p0DnJO/+/EzNej9eY45TFhFk13uB3dJ01DOM7SqwgddXdSqfCJR7usbpLL1 8fE0cpxeDstBXehm822VHrI8K34kRJMipbWXB2sqatTJdvt8Kotv4Zmp/mwS9TExVNP0 8BzMLOkiPhpZrhgonX0OQo25TC1rjHPPeVU4A1LhlE8e8RTkdoXKlb33rUOb0cilVrYm W47BQtYr3T6Y32unf99NIvkSd0CWHjW7yzJ7JpruOWUybZrXoNO7v6mmtECC3WnmXbW6 Rznw== X-Gm-Message-State: AHYfb5hu0Ggx7tixnLp/tKXLw04oJeb+KCTuGyR0C++zHFzuIaMeUZqx BSuw4zGq1dl66wvX69s= X-Received: by 10.46.22.20 with SMTP id w20mr423664ljd.103.1502386320074; Thu, 10 Aug 2017 10:32:00 -0700 (PDT) Received: from [192.168.1.105] (c83-251-251-174.bredband.comhem.se. [83.251.251.174]) by smtp.gmail.com with ESMTPSA id g25sm1057250ljd.25.2017.08.10.10.31.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 10:31:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Question on mountd From: Olavi Kumpulainen In-Reply-To: <1502380286.50720.97.camel@freebsd.org> Date: Thu, 10 Aug 2017 19:31:57 +0200 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4A19CA1E-C344-42AF-AAB2-E3095F2680A7@gmail.com> References: <1502380286.50720.97.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 17:32:03 -0000 Thanks Ian, Just a small follow up question - The reason to why -S works is that = mountd cannot interrupt the execution thread of a NFS request from a = client? Is this true in a multicore system as well? /Olavi > On 10 Aug 2017, at 17:51 , Ian Lepore wrote: >=20 > On Thu, 2017-08-10 at 16:56 +0200, Olavi Kumpulainen wrote: >> Hi guys, >>=20 >> I notice that mount SIGHUP=E2=80=99s mountd every time mount = succeeds. The >> SIGHUP causes mountd to remount all exported directories.If this >> happens while a NFS-client is accessing a share, an access error may >> occur. >> For this purpose, there is an option to mount, -S, which locks nfsd >> while the remount is executing. >>=20 >> Can anyone of you share why mount needs to SIGHUP mountd in the first >> place? It would make sense if mountd is restarted whenever >> /etc/exports is modified, but always seems like overkill. >>=20 >=20 > Based on looking through the mountd code a bit... When a new = filesystem > is mounted, it may be mounted on one of the mount points listed in > /etc/exports. If there was no fs mounted there previously, then = mountd > might have failed to set the in-kernel export attributes the last time > it processed the exports file, so it has to do the processing again > after the mount to update the in-kernel export data. It would be > really complex for mountd to try to figure out the minimal set of = "what > changed" after a mount succeeds, so it just completely reprocesses the > exports file, first removing all export data from the kernel, then re- > applying it all. >=20 > So, all in all, I think the right fix for this is to add > "mountd_flags=3D"-r -S" to your rc.conf file (-r is a default from > /etc/defaults/rc.conf). >=20 > -- Ian From owner-freebsd-arm@freebsd.org Thu Aug 10 17:41:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7FD7DD892B for ; Thu, 10 Aug 2017 17:41:11 +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 AC5656AAA7 for ; Thu, 10 Aug 2017 17:41:11 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 218bffc9-7df3-11e7-bfd0-afd4446ba3af X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 218bffc9-7df3-11e7-bfd0-afd4446ba3af; Thu, 10 Aug 2017 17:41:25 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v7AHf2Xl003973; Thu, 10 Aug 2017 11:41:02 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1502386862.50720.104.camel@freebsd.org> Subject: Re: Question on mountd From: Ian Lepore To: Olavi Kumpulainen Cc: freebsd-arm@freebsd.org Date: Thu, 10 Aug 2017 11:41:02 -0600 In-Reply-To: <4A19CA1E-C344-42AF-AAB2-E3095F2680A7@gmail.com> References: <1502380286.50720.97.camel@freebsd.org> <4A19CA1E-C344-42AF-AAB2-E3095F2680A7@gmail.com> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 17:41:11 -0000 On Thu, 2017-08-10 at 19:31 +0200, Olavi Kumpulainen wrote: > Thanks Ian, > > Just a small follow up question - The reason to why -S works is that > mountd cannot interrupt the execution thread of a NFS request from a > client? > Is this true in a multicore system as well? > With -S, mountd sends a NFSSVC_SUSPENDNFSD command to nfsd, which I presume makes nfsd finish any client requests in progress and stop handling new client requests, then mountd manipulates the in-kernel data, then it sends NFSSVC_RESUMENFSD.  I think the net effect is that no client requests which rely on the in-kernel mount-export data can be processed while mountd is manipulating the data.  You would think this would be the default behavior, but maybe the delays are so bad for some use cases that it was made optional with -S. I should note I'm not an expert on this stuff, I'm making a lot of assumptions from a little bit of looking at code. -- Ian > /Olavi > > > > > > On 10 Aug 2017, at 17:51 , Ian Lepore wrote: > > > > On Thu, 2017-08-10 at 16:56 +0200, Olavi Kumpulainen wrote: > > > > > > Hi guys, > > > > > > I notice that mount SIGHUP¢s mountd every time mount succeeds. > > > The > > > SIGHUP causes mountd to remount all exported directories.If this > > > happens while a NFS-client is accessing a share, an access error > > > may > > > occur. > > > For this purpose, there is an option to mount, -S, which locks > > > nfsd > > > while the remount is executing. > > > > > > Can anyone of you share why mount needs to SIGHUP mountd in the > > > first > > > place? It would make sense if mountd is restarted whenever > > > /etc/exports is modified, but always seems like overkill. > > > > > Based on looking through the mountd code a bit... When a new > > filesystem > > is mounted, it may be mounted on one of the mount points listed in > > /etc/exports.  If there was no fs mounted there previously, then > > mountd > > might have failed to set the in-kernel export attributes the last > > time > > it processed the exports file, so it has to do the processing again > > after the mount to update the in-kernel export data.  It would be > > really complex for mountd to try to figure out the minimal set of > > "what > > changed" after a mount succeeds, so it just completely reprocesses > > the > > exports file, first removing all export data from the kernel, then > > re- > > applying it all. > > > > So, all in all, I think the right fix for this is to add > > "mountd_flags="-r -S" to your rc.conf file (-r is a default from > > /etc/defaults/rc.conf). > > > > -- Ian > From owner-freebsd-arm@freebsd.org Fri Aug 11 05:22:49 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B0EEDB78C3 for ; Fri, 11 Aug 2017 05:22:49 +0000 (UTC) (envelope-from wlosh@bsdimp.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 C26E112AD for ; Fri, 11 Aug 2017 05:22:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x230.google.com with SMTP id g35so16636217ioi.3 for ; Thu, 10 Aug 2017 22:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=YSg36A5k3F0XfZ0Y3uaklzqYYIqkJ7W0NGH7yPzByrM=; b=sEXJwsn8JNANq3e5A0PVOjmyTD4y01EFoiRb0RxALfggxtwKRLEdm3JGXMwg8HL3vR vwu06HiR1gcvl+vAXye6Uzb7n/uY4yaMqBnoZinuvdCENBNvnBmtSnGZvkWIcj+f+xIX 2H4e/4OB1NUaHot7LTs/PuyHlXPILElyDiPNwuOcIrlpoMwG+N4WCxfAanofZZqT7XOA oE2ceaEHqjE5Bq5Y09Y9KL+WbL01lrea3itjvIGe04GLjyW4Ml2LuSUph65y5FB7H8SS UCehQ2sMU5FlnoLMpUveP8DxP/bBsfOoYHjdEw7O2Eb2I6uB7NyVENN4/Xi5aKd6TPuE MD4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=YSg36A5k3F0XfZ0Y3uaklzqYYIqkJ7W0NGH7yPzByrM=; b=Xh0mmdDiSK99/ZkF7WOSVde6PAXAs9lanXSEkHQkBKxeGXpbgRYQB119aBJei6DvUO bxc6Z4j/qcfpdPRlDRM+bTiukyT7Yy6TCa2JZbaX6a88zojqvD3q3prFyMwEt2YkMq+b TvSiYm6EDIZXHXgqodlkrsmwi63XbWmERhcRqZBlrkpF6PcMvLtdTfNJ+qeJTvpCHST+ vYNMMNs5n+BE61KgBHvmkBW8hzxg6Bm4ZZv+2z14z6cAb/o7i2glOzem/SH3mh6rlSvm TVNoUcXVZx57fzo8IDXLAgTKLGODsH9kvQzBghchEA2FpoOu6Y+TrU+M+bF9st6w5YNS qG5w== X-Gm-Message-State: AHYfb5g27xGoIA78tXaHVsPZBEyEULXi520cMkLxd/oR5kahYuh05c7z /NjHIjOf6F8K5rxsLianBEFa0RDEoZa+ X-Received: by 10.107.136.104 with SMTP id k101mr11753526iod.62.1502428967567; Thu, 10 Aug 2017 22:22:47 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Thu, 10 Aug 2017 22:22:46 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:fc73:9056:67a0:a7d0] From: Warner Losh Date: Thu, 10 Aug 2017 23:22:46 -0600 X-Google-Sender-Auth: 2tZ1xD69zVlvKpNvXVvIQ2VtxAU Message-ID: Subject: New Arch: armv7 To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 05:22:49 -0000 As discussed here in June, we're creating a new arch. I've landed on the armv7 name (as opposed to earmv7hf or armv7l) for the following reasons: 1. armv7 isn't a huge amount of work to implement in our tree, while the other two names require substantially more complicated .if statements in makefiles. 2. Neither of the other names actually buy us a large amount in the ports. Autoconf is split and many other ports do different things to get the system they are running on and wouldn't benefit from the other names. There's a small number of ports that might be better, but not enough to justify the extra work in base. 3. It's more like the names we've been using, and won't cause confusion with our user base. And it will be easy enough for outsiders to see what we support from it without needing the decoder ring for NetBSD, or dealing with 'what's the trailing l mean, why doesn't armv6 have it, or arm and what about armeb' all the time. btw, if we ever do a big endian port, armv7eb will be the name, per project tradition. So, I'll be finalizing FCP-0100 with this data (I've sent the pull request) and will get an implementation together (I have the start of one I was able to knock out in about an hour, after spending twice that on the other two choices w/o reaching completion) and if there's issues that arise as we move forward, cope with them on the way to asking core to vote to bless this is the consensus of the relevant parts of the community. I hope to have it committed by the end of the month, and hope that the FCP process won't unduly delay things. Warner From owner-freebsd-arm@freebsd.org Fri Aug 11 09:18:02 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07654DB583E for ; Fri, 11 Aug 2017 09:18:02 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 8A1FE68A3E for ; Fri, 11 Aug 2017 09:18:01 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id f15so42381437wmg.1 for ; Fri, 11 Aug 2017 02:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SiRY35YuLsSqkZ6tJ0DnY/yBgQRg8ZTpBK120X0vFNU=; b=fPi4zwE6EOPpR4MYmlDivmW9rcHu8AbVl4lUTrz2liWognGG6PIc5NyPqk7sbkNGGB gDWA2e0pBchiYqdMJdJncGlX4NWh317DGEl6NKlf7g7g+74zFHsToo/gMyVTNYxwbxoA u7eUaqU3eBdPJmodnRVEy7ZaSutKZGEDiRmS0FuvOXtOuEi+r6aAVP2pnESXnhr3agVF gK0zOnMiiDDlVf8PB7kEM6OmnOGYGYi8TVL+qUqIchE6HEJo5NggkE9SGs8SRlx0xOaH wCUgFy78YMVQOZMPwu7sHWISUYkRLagQB+34P/uVMqnCpuN00q5XdfFpIgeevlfZMSGy dwPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SiRY35YuLsSqkZ6tJ0DnY/yBgQRg8ZTpBK120X0vFNU=; b=BLg7dZBCJGUEmPNcvl4+GTIPquixYmqGONBq+bL7Ko5ilFjIplyoLHOX3+wKyjkazU 1Lzb0egR4FnlFrmX1QXbxMGHwFRIjnpav5T1XVXIM2wm5s3S1+9YI1vWL9VvZv1nx4vr svJba7nSZJDampbuqkqQvNZ8eQJiwA0MAIiW5XXl6+2D3RIQOkLqVSGYMSrwbEjlvjUK K16vuUhZQRNmC+rm5/S6uQyvNDCzXRFQYuIptdTq58nwy71KS0k30suhyONkmWK8jDZS qfbeDZFVNA7zPs/W92wBXVWtLux1TKz77G9a5uXSkCFOOQnl1BnmlTQPfiRRM7VqFIZH ogRA== X-Gm-Message-State: AHYfb5hqPKYqGUuzGCPBXbQ0vM6SWwWaaqGqUUWm0QE3KtRiOqP12j6h m0mPIpQ+y2qF2LB1/+U= X-Received: by 10.28.188.85 with SMTP id m82mr8743518wmf.3.1502443079853; Fri, 11 Aug 2017 02:17:59 -0700 (PDT) Received: from [172.21.11.95] (static-css-csd-147253.business.bouyguestelecom.com. [176.162.147.253]) by smtp.gmail.com with ESMTPSA id t13sm442135wra.22.2017.08.11.02.17.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 02:17:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: New Arch: armv7 From: Sylvain Garrigues In-Reply-To: Date: Fri, 11 Aug 2017 11:17:58 +0200 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9A7B10D6-93FD-4C71-A285-DDD295053988@gmail.com> References: To: Warner Losh X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 09:18:02 -0000 This is excellent news, thank you so much for your hard work! > Le 11 ao=C3=BBt 2017 =C3=A0 07:22, Warner Losh a = =C3=A9crit : >=20 > As discussed here in June, we're creating a new arch. >=20 > I've landed on the armv7 name (as opposed to earmv7hf or armv7l) for = the > following reasons: >=20 > 1. armv7 isn't a huge amount of work to implement in our tree, while = the > other two names require substantially more complicated .if statements = in > makefiles. > 2. Neither of the other names actually buy us a large amount in the = ports. > Autoconf is split and many other ports do different things to get the > system they are running on and wouldn't benefit from the other names. > There's a small number of ports that might be better, but not enough = to > justify the extra work in base. > 3. It's more like the names we've been using, and won't cause = confusion > with our user base. And it will be easy enough for outsiders to see = what we > support from it without needing the decoder ring for NetBSD, or = dealing > with 'what's the trailing l mean, why doesn't armv6 have it, or arm = and > what about armeb' all the time. >=20 > btw, if we ever do a big endian port, armv7eb will be the name, per = project > tradition. >=20 > So, I'll be finalizing FCP-0100 with this data (I've sent the pull = request) > and will get an implementation together (I have the start of one I was = able > to knock out in about an hour, after spending twice that on the other = two > choices w/o reaching completion) and if there's issues that arise as = we > move forward, cope with them on the way to asking core to vote to = bless > this is the consensus of the relevant parts of the community. >=20 > I hope to have it committed by the end of the month, and hope that the = FCP > process won't unduly delay things. >=20 > Warner > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Fri Aug 11 09:35:37 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3919DB6C66 for ; Fri, 11 Aug 2017 09:35:37 +0000 (UTC) (envelope-from sylvain@sylvaingarrigues.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5559469C0F for ; Fri, 11 Aug 2017 09:35:37 +0000 (UTC) (envelope-from sylvain@sylvaingarrigues.com) Received: by mail-wm0-x231.google.com with SMTP id i66so42748356wmg.0 for ; Fri, 11 Aug 2017 02:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sylvaingarrigues-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AobsdKfJxlS/hE8giYteKkqwZrxwGkN4onFFGwADTio=; b=t8bq2FU6kwbxdkddI5V6kvxYOu3s1hGf0+WYDT/CBvNbFy+Cc3KaRq2OL3WWUKUF3N C4R7ZdZLKk4gKw8Bu2Lob6Nlr9aPZOPoAEPFBMjCzje3UvExD4Ff7hoQV0eDkYcsq83q 0nMG2M0juVJ/b5NzYwW1lYbkatMLHjh8YbxxlbcsDE/HpcoxcGX0eVx6vWX/cD/xkruo FWIZDoNjYIzNoBu2K1LiLzKMx5wMyOoW/TmvnMjg4X4GTw5cQdrHsQ1dFf0VvplnCgSw /tSxgUdSTnnmEc1kCMvWIltTq4dBLfjW6INX7l1zgBI+eEyqc2fXIS+4MHXNnnHQB8F4 KxEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AobsdKfJxlS/hE8giYteKkqwZrxwGkN4onFFGwADTio=; b=lOwUOXRrf9JJm4WdANqXSgLAhi0cPPnvHEW9/kuhWQjOUV1RY4ntfXqkzkBui2uCVG kAwei9cMno9Vm28HVnqTFZ4JyLvj3981PfGKMzPrNWZE1SjKpLDOIUYSAJAOwbOrL9x0 YG7W4tik1DkgiaSNvMOE+RHENIqvP/L+gNEfjlUSDb7V5ITTmDuGzfCaPl8Qkjck5yJC 4YtHixPxA0+Aa9nA3h7INStbKZAoRoUaJzfhuuyw26J1q8y0rZzTPBrpS0eUNnjuUi1R MavAnhaOLEq+k0Y22jqrxE0yxEsaetSVa4Q8nrzMJGUVZz5rCZiEOFnJiiw0awzWSL4C vJDQ== X-Gm-Message-State: AHYfb5hTNSZF6bvoPDuTxqcn1CsdARSKEG78E9hpO5mFYI+S5TW66/D3 0VVdzo1HfFK3dUcfddYYe31JqAJq+xgebSk= X-Received: by 10.80.150.196 with SMTP id z4mr15407250eda.184.1502444135560; Fri, 11 Aug 2017 02:35:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.129.229 with HTTP; Fri, 11 Aug 2017 02:35:35 -0700 (PDT) X-Originating-IP: [176.162.147.253] In-Reply-To: <11C8C2C2-02FA-493A-816E-5ED0653EAF78@dsl-only.net> References: <8910A9FB-E936-4576-97B1-B2EDCB1ED1AE@dsl-only.net> <11C8C2C2-02FA-493A-816E-5ED0653EAF78@dsl-only.net> From: Sylvain Garrigues Date: Fri, 11 Aug 2017 11:35:35 +0200 Message-ID: Subject: Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode To: Mark Millard Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 09:35:37 -0000 Actually, with latest u-boot and static RPI2 DTB embedded in kernel, I've managed to make the RPI2 kernel boot on my RPI3 and recognize all cortex-a53 processors. I've got errors then because the DTB mustn't be static, the RPI firmware patches it with required values before giving control to kernel. I still need to figure out why the kernel doesn't like the DTB provided by firmware when it's not static, and panics with "OF_init failed with the found device tree" in initarm, but apart from that I feel like we are close to having a 32-bit OS for RPI3 and new RPI2 v1.2. Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #45 14d0c5770e7(master)-dirty: Fri Aug 11 17:31:04 CEST 2017 root@box.sylvaingarrigues.com:/usr/obj/arm.armv6/usr/src/sys/GENERIC arm FreeBSD clang version 5.0.0 (branches/release_50 309439) (based on LLVM 5.0.0svn) VT: init without driver. CPU: ARM Cortex-A53 r0p4 (ECO: 0x00000080) CPU Features: Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, VMSAv7, PXN, LPAE, Coherent Walk Optional instructions: SDIV/UDIV, UMULL, SMULL, SIMD(ext) LoUU:2 LoC:3 LoUIS:2 Cache level 1: 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc 32KB/64B 2-way instruction cache Read-Alloc Cache level 2: 512KB/64B 16-way unified cache WB Read-Alloc Write-Alloc ... 2017-08-10 18:04 GMT+02:00 Mark Millard : > On 2017-Aug-10, at 6:51 AM, Sylvain Garrigues sylvaingarrigues.com> wrote: > > > 2017-08-10 1:58 GMT+02:00 Mark Millard : > >> Overall: Supporting aarch32 is not automatic > >> even if one starts from armv7 or specifically > >> a cortex-a53 context unless one was lucky > >> enough to happen to not touch or depend on > >> any of the differences at any stage. > > > > Thanks. I guess though that it's quite easily feasible for someone > familiar with arm lower level initialization. > > > > I can see NetBSD managed to make the armv7 kernel boot on Raspberry Pi 3 > with one commit: > > Get the RPI3 working (in aarch32 mode) by recognising Cortex A53 CPUs. - > https://github.com/IIJ-NetBSD/netbsd-src/commit/ > 00335f7adc380a125d045279c1a0f5525fb557da > > Interesting. > > > Same for OpenBSD folks: > > http://marc.info/?l=openbsd-tech&m=145692659524971&w=2 > > This one (OpenBSD) says (note the "including some other > (still) local diffs"): > > "This way, and including some other (still) local diffs, I have > the brand new raspberry Pi 3 in multiuser: http://ix.io/oJV " > > So the reference only has some of of the code changes shown. > > And the boot log shows: > > cpu0 at mainbus0: ARM Cortex A53 rev 4 (ARMv7 core) > cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled > cpu0: 32KB(64b/l,2way) I-cache, 32KB(64b/l,4way) wr-back D-cache > > So just one cpu. But for all I know OpenBSD might not have > been SMP capable on a rpi2 at the time either. > > The boot log also shows: > > gpio at bcmgpio0 not configured > broadcom0: device bcmsdhc unit 0 not found > > > So for OpenBSD the code change shown was just the start of the > update as far as I can tell. > > > Plus FreeBSD's RPI2 armv6 kernel does boot and recognize the cortex-a53 > with qemu-aarch64: > > qemu-system-aarch64 -M raspi2 -cpu cortex-a53 -m 1024 -smp 4 -kernel > kernel.bin -serial stdio -dtb rpi2.dtb > > Interesting. How clean is the boot log? > > At least for raspbian there were separate files for rpi3 > when rpi3 was first supported: > > arch/arm/boot/dts/bcm2710-rpi-3-b.dts > arch/arm/boot/dts/bcm2710.dtsi > > Later there was: > > arch/arm/boot/dts/overlays/pi3-disable-bt-overlay.dts > arch/arm/boot/dts/overlays/pi3-miniuart-bt-overlay.dts > arch/arm/boot/dts/overlays/pi3-disable-wifi-overlay.dts > arch/arm/boot/dts/overlays/pi3-act-led-overlay.dts > > as well as some updates to some of those files. (I'm > not sure that I found all such files that are rpi3 > specific [possibly covering rpi2v1.2 as well?].) > > I suspect the qemu-system-aarch64 use is simulating > a rpi2's details as listed in rpi2.dtb instead of the > rpi3's details. (But using a cortex-a53 CPU model.) > There may well be work in supporting the rpi3's > details in the kernel and/or boot loading stages for > all I know. > > What happens if a rpi3 dtb file is used instead of > rpi2.dtb ? > > > > So I guess we too are really not far to boot RPI2 "armv6" kernel on > raspberry pi 2 v1.2 and raspberry pi 3. > > I wish I could help. > > Since I'm finding these things as I go I've no clue > what I've not found. So I can not tell how close to > correct you are. > > > === > Mark Millard > markmi at dsl-only.net > > > > From owner-freebsd-arm@freebsd.org Sat Aug 12 14:20:53 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B55A0DD96AA for ; Sat, 12 Aug 2017 14:20:53 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 532E03484 for ; Sat, 12 Aug 2017 14:20:53 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=2001:41d0:8:bdbe:1:1::; helo=restart.be; envelope-from=hlh@restart.be; receiver=freebsd-arm@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3xV3ty1MGYzsNr DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1502547642; bh=2WnNSlraW3jLlzb2obS/MprDlPi+8NMsRvX+HnSHA4g=; h=Subject:To:References:From:Date:In-Reply-To; z=Subject:=20Re:=20PINE64+=20Release=20APs,=20APs=20not=20started=2 0-=20a=20solution...|To:=20freebsd-arm@freebsd.org|References:=20< 79dd24d5-9669-a767-be2a-0e84bc4d22ae@restart.be>|From:=20Henri=20H ennebert=20|Date:=20Sat,=2012=20Aug=202017=2016:20 :39=20+0200|In-Reply-To:=20<79dd24d5-9669-a767-be2a-0e84bc4d22ae@r estart.be>; b=nDg++NlEudRufaQd4b41w1N1ENOm3bLSKrnIlfzAHRNLsu8HSTjuhVsfR3R69yAXd EgTzODbD2BIVjY9RbEOR0/8Tab/uINKSaqpukSrNESYai9eLQrVzCdGjHaY5vsZ4bi P33FUZCPqKrzLiy025YptWGRB0CjU2QepAJXfnIY8cPo8GBMqD9O3sXOgWa9b2v1Et J0JPxiFt7vAMDS3VJaJ5UbkpHICgbxhqp7+bq91O0Ww5BEwAKOsTpcV9NSLBSS8ST8 dKH3mnLgaUJGS/ciMda1ZnJ1ObZH3TpnUUKFNzHiDItEewU5PiNPsahSlPs1oFqqh4 LZsOfHDe2igiw== Received: from restart.be (avoriaz.restart.be [IPv6:2001:41d0:8:bdbe:1:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3xV3ty1MGYzsNr for ; Sat, 12 Aug 2017 16:20:41 +0200 (CEST) Received: from chamonix.restart.bel (chamonix.restart.bel [IPv6:2001:41d0:8:bdbe:1:9:0:0]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id v7CEKdZM044702 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 12 Aug 2017 16:20:40 +0200 (CEST) (envelope-from hlh@restart.be) Subject: Re: PINE64+ Release APs, APs not started - a solution... To: freebsd-arm@freebsd.org References: <79dd24d5-9669-a767-be2a-0e84bc4d22ae@restart.be> From: Henri Hennebert Message-ID: Date: Sat, 12 Aug 2017 16:20:39 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <79dd24d5-9669-a767-be2a-0e84bc4d22ae@restart.be> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 14:20:53 -0000 On 07/25/2017 19:22, Henri Hennebert wrote: > Hello, > > With FreeBSD 12.0-CURRENT #0 r320599 I can boot normally: > > ... > Release APs > CPU 0: ARM Cortex-A53 r0p4 affinity: 0 > Instruction Set Attributes 0 = > Instruction Set Attributes 1 = <0> > Processor Features 0 = 32> > Processor Features 1 = <0> > Memory Model Features 0 = <4k Granule,64k > Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> > Memory Model Features 1 = <> > Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6 > Breakpoints,PMUv3,Debug v8> > Debug Features 1 = <0> > Auxiliary Features 0 = <0> > Auxiliary Features 1 = <0> > CPU 1: ARM Cortex-A53 r0p4 affinity: 1 > CPU 2: ARM Cortex-A53 r0p4 affinity: 2 > CPU 3: ARM Cortex-A53 r0p4 affinity: 3 > ... > > With r320869, I get > > Release APs > APs not started > x0: ffff000000977d80 > x1: fffffd000299ba80 > x2: 3 > > I succeed one time to boot with r321003 but after that I try multiple > times and get the same error: APs not started > > I try r321371 to no avail. > > Any idea ? > > Henri If I boot with kernel r320599 (unload; load /boot/kernel.r320599/kernel; set module_path=/boot/kernel.r320599; load zfs; load opensolaris; boot), the boot complete without problem. Then I do a shutdown -r now to reboot with my default kernel (/boot/kernel) the boot complete without problem: [root@norquay ~]# uname -a FreeBSD norquay.restart.bel 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r322109M: Wed Aug 9 17:16:41 CEST 2017 root@norquay.restart.bel:/usr/obj/usr/src/sys/NORQUAY arm64 with my rpool on 2 USB disks connected to a self powered hub: root@norquay ~]# zpool status pool: rpool state: ONLINE scan: scrub repaired 0 in 3h3m with 0 errors on Sat Jul 29 16:33:00 2017 config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/disk0-zfs ONLINE 0 0 0 gpt/disk1-zfs ONLINE 0 0 0 errors: No known data errors BUT after a power off power on, this same kernel encounter the APs not started error. If I boot with /boot/kernel.r320599 and then do a shutdown -r now the r322109 boot without problem. Henri