From owner-freebsd-arm@freebsd.org Sun Apr 30 03:29:12 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9447ED56913 for ; Sun, 30 Apr 2017 03:29:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-51.reflexion.net [208.70.210.51]) (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 4BC94363 for ; Sun, 30 Apr 2017 03:29:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32072 invoked from network); 30 Apr 2017 03:32:18 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 30 Apr 2017 03:32:18 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 29 Apr 2017 23:29:04 -0400 (EDT) Received: (qmail 9438 invoked from network); 30 Apr 2017 03:29:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Apr 2017 03:29:04 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5E720EC8029; Sat, 29 Apr 2017 20:29:03 -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: FYI: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw under qemu-system-aarch64 on odroid-c2 under UbuntuMate : No valid device tree blob found! Message-Id: Date: Sat, 29 Apr 2017 20:29:02 -0700 To: freebsd-arm , FreeBSD Current 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: Sun, 30 Apr 2017 03:29:12 -0000 With: = http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upst= ream/1917/QEMU-AARCH64/RELEASE_CLANG35/QEMU_EFI.fd for QEMU_EFI.fd and with: = http://ftp1.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/12.0-CURRENT/aarch= 64/20170420/FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw.xz for FreeBSD's .raw file (after unxz) I tried: qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -M virt \ -bios QEMU_EFI.fd -nographic \ -drive = format=3Draw,if=3Dnone,file=3DFreeBSD-12.0-CURRENT-arm64-aarch64-20170420-= r317181.raw,id=3Dhd0 \ -device virtio-blk-device,drive=3Dhd0 \ -device virtio-net-device,netdev=3Dnet0 \ -netdev user,id=3Dnet0 \ -smp cpus=3D4 on an odroid-c2 running UbuntuMate: # uname -a Linux odroidc2UbMate 3.14.79-110 #1 SMP PREEMPT Tue Apr 11 20:16:54 BRT = 2017 aarch64 aarch64 aarch64 GNU/Linux The result was: . . . Booting [/boot/kernel/kernel]... =20 No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! . . . generic_timer0: irq 29,30,27 on acpi0 panic: Attempt to copy invalid resource id: 29 In full detail: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 5 block devices.......* done ZFS found no pools UFS found 1 partition Consoles: EFI console =20 Command line arguments: loader.efi Image base: 0x763b1000 EFI version: 2.60 EFI Firmware: EDK II (rev 1.00) FreeBSD/arm64 EFI loader, Revision 1.1 (Thu Apr 20 16:51:44 UTC 2017 root@releng3.nyi.freebsd.org) EFI boot environment Loading /boot/defaults/loader.conf /boot/kernel/kernel text=3D0x7b6848 data=3D0xa0578+0x43b3be = syms=3D[0x8+0x106938+0x8+0xfb67b] \ Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! 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 r317181: Thu Apr 20 16:54:23 UTC 2017 = root@releng3.nyi.freebsd.org:/usr/obj/arm64.aarch64/usr/src/sys/GENERIC = arm64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs arc4random: no preloaded entropy cache random: entropy device external interface kbd0 at kbdmux0 acpi0: acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) psci0: on acpi0 generic_timer0: irq 29,30,27 on acpi0 panic: Attempt to copy invalid resource id: 29 cpuid =3D 0 time =3D 1 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff0000005db8a0 lr =3D 0xffff000000088910 sp =3D 0xffff0000000102a0 fp =3D 0xffff0000000104b0 db_trace_self_wrapper() at vpanic+0x184 pc =3D 0xffff000000088910 lr =3D 0xffff00000030a774 sp =3D 0xffff0000000104c0 fp =3D 0xffff000000010540 vpanic() at panic+0x48 pc =3D 0xffff00000030a774 lr =3D 0xffff00000030a800 sp =3D 0xffff000000010550 fp =3D 0xffff0000000105d0 panic() at intr_map_copy_map_data+0x164 pc =3D 0xffff00000030a800 lr =3D 0xffff000000616600 sp =3D 0xffff0000000105e0 fp =3D 0xffff000000010630 intr_map_copy_map_data() at intr_activate_irq+0xd8 pc =3D 0xffff000000616600 lr =3D 0xffff000000616280 sp =3D 0xffff000000010640 fp =3D 0xffff000000010690 intr_activate_irq() at nexus_activate_resource+0xb8 pc =3D 0xffff000000616280 lr =3D 0xffff0000005e77b8 sp =3D 0xffff0000000106a0 fp =3D 0xffff0000000106d0 nexus_activate_resource() at nexus_alloc_resource+0x10c pc =3D 0xffff0000005e77b8 lr =3D 0xffff0000005e76cc sp =3D 0xffff0000000106e0 fp =3D 0xffff000000010730 nexus_alloc_resource() at resource_list_alloc+0x1d4 pc =3D 0xffff0000005e76cc lr =3D 0xffff00000033bf94 sp =3D 0xffff000000010740 fp =3D 0xffff000000010790 resource_list_alloc() at acpi_alloc_resource+0x17c pc =3D 0xffff00000033bf94 lr =3D 0xffff0000000924fc sp =3D 0xffff0000000107a0 fp =3D 0xffff000000010850 acpi_alloc_resource() at bus_alloc_resources+0xd8 pc =3D 0xffff0000000924fc lr =3D 0xffff00000033dfa4 sp =3D 0xffff000000010860 fp =3D 0xffff0000000108b0 bus_alloc_resources() at arm_tmr_attach+0xc8 pc =3D 0xffff00000033dfa4 lr =3D 0xffff0000005ca394 sp =3D 0xffff0000000108c0 fp =3D 0xffff0000000108f0 arm_tmr_attach() at device_attach+0x404 pc =3D 0xffff0000005ca394 lr =3D 0xffff00000033b60c sp =3D 0xffff000000010900 fp =3D 0xffff000000010950 device_attach() at bus_generic_attach+0x50 pc =3D 0xffff00000033b60c lr =3D 0xffff00000033c808 sp =3D 0xffff000000010960 fp =3D 0xffff000000010980 bus_generic_attach() at acpi_attach+0xd44 pc =3D 0xffff00000033c808 lr =3D 0xffff000000091b98 sp =3D 0xffff000000010990 fp =3D 0xffff000000010a40 acpi_attach() at device_attach+0x404 pc =3D 0xffff000000091b98 lr =3D 0xffff00000033b60c sp =3D 0xffff000000010a50 fp =3D 0xffff000000010aa0 device_attach() at bus_generic_new_pass+0x120 pc =3D 0xffff00000033b60c lr =3D 0xffff00000033ced0 sp =3D 0xffff000000010ab0 fp =3D 0xffff000000010ae0 bus_generic_new_pass() at bus_generic_new_pass+0xe4 pc =3D 0xffff00000033ced0 lr =3D 0xffff00000033ce94 sp =3D 0xffff000000010af0 fp =3D 0xffff000000010b20 bus_generic_new_pass() at bus_set_pass+0x8c pc =3D 0xffff00000033ce94 lr =3D 0xffff000000339114 sp =3D 0xffff000000010b30 fp =3D 0xffff000000010b60 bus_set_pass() at mi_startup+0xc8 pc =3D 0xffff000000339114 lr =3D 0xffff0000002a8c34 sp =3D 0xffff000000010b70 fp =3D 0xffff000000010bb0 mi_startup() at virtdone+0x54 pc =3D 0xffff0000002a8c34 lr =3D 0xffff000000001084 sp =3D 0xffff000000010bc0 fp =3D 0x0000000000000000 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x40: undefined d4200000 db>=20 Historical note: I last tried this sort of thing was back in 2016-September with 11-RELEASE and it booted but there were later problems. I tried the above because of the two recent fixes that remove aarch64-specific problems that were happening during fork. (There is no snapshot of stable/11 that has both of those fixes yet --and I've been using CURRENT anyway.) Some notes from back in 2016-August through 2016-October by other folks are at: https://forum.odroid.com/viewtopic.php?t=3D23356 The Odroid-C2 has also had various software updates since my earlier attempt so nothing has a known-good status for the purpose as far as my history goes. I can not lay blame as stands. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Apr 30 08:58:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7F17D572F3; Sun, 30 Apr 2017 08:58:24 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 97318839; Sun, 30 Apr 2017 08:58:24 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [IPv6:2a02:c7f:1e13:cf00:4f9:7787:8c3e:8b31] (unknown [IPv6:2a02:c7f:1e13:cf00:4f9:7787:8c3e:8b31]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 0EADF4E79B; Sun, 30 Apr 2017 08:57:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw under qemu-system-aarch64 on odroid-c2 under UbuntuMate : No valid device tree blob found! From: Andrew Turner In-Reply-To: Date: Sun, 30 Apr 2017 09:57:44 +0100 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: References: To: Mark Millard 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: Sun, 30 Apr 2017 08:58:24 -0000 > On 30 Apr 2017, at 04:29, Mark Millard wrote: > ... > acpi0: > acpi0: Power Button (fixed) > acpi0: Sleep Button (fixed) ACPI is not fully supported on arm64. Andrew From owner-freebsd-arm@freebsd.org Sun Apr 30 10:27: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 6C7C7D576D9 for ; Sun, 30 Apr 2017 10:27:08 +0000 (UTC) (envelope-from aggaz@paranoici.org) Received: from perdizione.investici.org (perdizione.investici.org [IPv6:2001:41d0:2:33d0::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.autistici.org", Issuer "Autistici/Inventati Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3ABF71B17 for ; Sun, 30 Apr 2017 10:27:07 +0000 (UTC) (envelope-from aggaz@paranoici.org) Received: from [94.23.50.208] (perdizione [94.23.50.208]) (Authenticated sender: aggaz@paranoici.org) by localhost (Postfix) with ESMTPSA id E2157120231 for ; Sun, 30 Apr 2017 10:27:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paranoici.org; s=stigmate; t=1493548025; bh=CT0HiPVtBzJ7OGADsLieTlSftHaOJHBNY7vGKbhyL6A=; h=To:From:Subject:Date; b=uY1I1U8+CID4z4K7ngq2D0Uu8IBAT6DoZJQn3weO1eFgQpKQuMwlaosTqrTvLX213 bEJwBnMHM+iUrzTavrMaMHru2H6eQXW27xuzFgDCHMP+/KpYhT0k/oSUOflJCUeur2 DvG5W+bBiVnNWPhiI43XtjlRpqoRjFuHCtmGkcJo= To: freebsd-arm@freebsd.org From: aggaz Subject: Re: FreeBSD 12-CURRENT on OrangePi One Message-ID: <9e04f3cf-ddce-1b53-b9d6-2fe05ad1cc25@paranoici.org> Date: Sun, 30 Apr 2017 12:27:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 10:27:08 -0000 Dear list, as I previously wrote, I am trying to use FreeBSD 12-CURRENT on OrangePi One by using crochet. One problem is that there are no dtb files available specific for this board. Now I compared two dtb files for the same SoC (H3): one for NanoPi Neo (/boot/dtb/nanopi-neo.dtb) and one for OrangePi Plus 2E (/boot/dtb/orangepi-plus-2e.dtb). Both makes the board boot fine without issues, but: 1) dtb file for NanoPi Neo makes the network interface available and working, but not the USB port. 2) dtb file for OrangePi Plus 2E makes the USB port available and working, but not the network interface. At this point I don't really know what I can do to make both interfaces working at the same time, and I am writing this to ask you some suggestions. Any idea would be greatly appreciated. Regards Aggaz From owner-freebsd-arm@freebsd.org Sun Apr 30 11:02:30 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2BF2D571C3 for ; Sun, 30 Apr 2017 11:02:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-51.reflexion.net [208.70.210.51]) (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 591A01D0 for ; Sun, 30 Apr 2017 11:02:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25033 invoked from network); 30 Apr 2017 11:05:42 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Apr 2017 11:05:42 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sun, 30 Apr 2017 07:02:28 -0400 (EDT) Received: (qmail 21096 invoked from network); 30 Apr 2017 11:02:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Apr 2017 11:02:27 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3AC79EC7ED7; Sun, 30 Apr 2017 04:02:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw under qemu-system-aarch64 on odroid-c2 under UbuntuMate : No valid device tree blob found! From: Mark Millard In-Reply-To: Date: Sun, 30 Apr 2017 04:02:26 -0700 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> References: To: Andrew Turner 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: Sun, 30 Apr 2017 11:02:30 -0000 On 2017-Apr-30, at 1:57 AM, Andrew Turner wrote: >> On 30 Apr 2017, at 04:29, Mark Millard wrote: >> ... >> acpi0: >> acpi0: Power Button (fixed) >> acpi0: Sleep Button (fixed) > > ACPI is not fully supported on arm64. Good to know. Thanks. But the messages: No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! were well before the acpi0 messages so I'd expect that the lack of a "device tree blob" is a separate, earlier issue, likely to do with the content of: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw My old 2016-Sep. notes showed no such notifications for the 11-RELEASE attempt I made back then. (After the acpi0 messages:) I guessed that the "29"s in: generic_timer0: irq 29,30,27 on acpi0 panic: Attempt to copy invalid resource id: 29 were the same "29"s: i.e., that the "resource id" was the generic_time0: 29 irq number. But being after the acpi0 messages and after the notice of a lack of a "device tree blob" may be things are already messed up by that point --or may be my guess about the "29"s is just wrong and "resource id" 29 is something else, possibly related to the acpi0 notices. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Apr 30 11:07: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 A9ACCD573F7 for ; Sun, 30 Apr 2017 11:07:28 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3758C77E for ; Sun, 30 Apr 2017 11:07:28 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: by mail-wr0-x22f.google.com with SMTP id w50so53059737wrc.0 for ; Sun, 30 Apr 2017 04:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=uMzG8OINZLA6cALESEO3BFwPI3qdfBPM8PlzMJMsDqs=; b=ChT6QJJqNDPJqv9Mi1wMa52nnjXUAv6J2Vlm4R1RBSYTuj1XkEYM/EpWyHgxMGwb6B DwZAF+7CprVw0+ZJBX8kM+qn+bZfEcltyskaIXpZLNLxkv9ms+hoGlb9KBG2gbuiwkBB rmMBKXL6PjkTyCuo1HCJB3KJMmdX6AG8KoJxggT0BvCODkmC4DFjpT/zrQ592OaI5CEJ qDoKUKqgEJ7txrUHC3HLeuWkFhCABK0OpY0SNMejfqYagrQ8+X5qWB3KTeonlnPYdY7B JkWKUlxwTjK3Ad5gwqGeLzNFa823SGDpwtWIoWbefHjPp1JmCwMLQi758jY3LVS2hFMQ 1HSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:subject:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=uMzG8OINZLA6cALESEO3BFwPI3qdfBPM8PlzMJMsDqs=; b=p72UqUwlkyDztHP4czDvT3LtHwOzKPhbsBmncBuT1ue5Xk35cVYr8mPz+mZwTcx29E F2FVtRwPQx/t9W3SSSjzByfPQPydKl9wlXoKirP6dgHmUdkktrOuyvTt9oO2QysG+UPx fgpoQ0+GZLidbHyDhD6Poey5H3jFDvIzsJRpaPlulkJH0t53giybo5KHhCIFNuakU8lb 4WFgt61LvhKPFjzwsKz9YwJ7RBHWXBiHci1JldTruTwky2hRs7LarX9+M1deBI74971K d9X55gFBjRbUZwCTBhcuYbNfCR/mrnRmGxrt3W4bM1fYMQRON349VTj1iKlR5EN4svmQ bWGg== X-Gm-Message-State: AN3rC/5Hlumdw/gBSuu3FoIVnvz7I2V0nDtXS+Ky490+5VmWuEgzPpWo xb/9YCnLI6ZHr7aV X-Received: by 10.223.165.138 with SMTP id g10mr14872831wrc.19.1493550445924; Sun, 30 Apr 2017 04:07:25 -0700 (PDT) Received: from ?IPv6:2a02:aa16:1103:d300::5? ([2a02:aa16:1103:d300::5]) by smtp.googlemail.com with ESMTPSA id y63sm10025025wme.31.2017.04.30.04.07.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Apr 2017 04:07:24 -0700 (PDT) From: Mattia Rossi X-Google-Original-From: Mattia Rossi Reply-To: mattia.rossi.mate@gmail.com To: ARM Subject: OrangePi-Plus-2 boot process hangs in ubldr.bin Message-ID: Date: Sun, 30 Apr 2017 13:07:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 11:07:28 -0000 Hi all, I've tried to upgrade u-boot on the OrangePi-Plus-2 (not the 2e) from mainline u-boot and on the outside it looks fine. U-boot loads, and it boots ubldr.bin. I'm using the orangepi-plus-2e.dtb as it has been working well for this board before (It all used to work). Now ubldr can't boot the kernel though, and I don't know why. I've rebuilt ubldr, world and kernel from svn. Revision number is 317594 Any help would be appreciated The output before it stops is: U-Boot SPL 2017.05-rc2-00061-g12af9399e7 (Apr 25 2017 - 19:27:44) DRAM: 2048 MiB Trying to boot from MMC1 U-Boot 2017.05-rc2-00061-g12af9399e7 (Apr 25 2017 - 19:27:44 +0200) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi Plus 2E I2C: ready DRAM: 2 GiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 In: serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 USB4: USB EHCI 1.00 USB5: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 4 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Booting from: mmc 0 ubldr.bin reading ubldr.bin 237168 bytes read in 34 ms (6.7 MiB/s) ## No elf image at address 0x42000000 ## Starting application at 0x42000000 ... Consoles: U-Boot console Compatible U-Boot API signature found @0xbbf3f690 FreeBSD/armv6 U-Boot loader, Revision 1.2 (Sat Apr 29 19:16:42 CEST 2017 root@freebsd101) DRAM: 2048MB MMC Device 2 not found MMC Device 3 not found Number of U-Boot devices: 2 U-Boot env: loaderdev='mmc 0' Found U-Boot device: disk Checking unit=0 slice= partition=... good. Booting from disk0s2: /boot/kernel/kernel data=0x6a82c0+0x1a7d40 syms=[0x4+0xba030+0x4+0xaa532] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/dtb/orangepi-plus-2e.dtb size=0x6326 Loaded DTB from file 'orangepi-plus-2e.dtb'. Kernel entry at 0x42200100... Kernel args: (null) The u-boot environment looks like this: => printenv Fatboot=echo Booting from: ${fatdev} ${bootfile}; fatload ${fatdev} ${kernel_addr_r} ${bootfile} && bootelf || go ${kernel_addr_r}; SetupFatdev=env exists fatdev || env set fatdev 'mmc 0'; api_address=bbf3f690 baudrate=115200 bootcmd=run Fatboot bootfile=ubldr.bin bootm_size=0xa000000 console=ttyS0,115200 eth1addr=12:81:5a:66:27:6f ethact=ethernet@1c30000 ethaddr=02:81:5a:66:27:6f fatdev=mmc 0 fdt_addr_r=0x43000000 fdtcontroladdr=bbf39b68 fdtfile=orangepi-plus-2e.dtb ipaddr=192.168.0.200 kernel_addr_r=0x42000000 loaderdev=mmc 0 preboot=usb start; env exists bootfile || env set bootfile ubldr.bin; env exists SetupFatdev && run SetupFatdev; env exists UserPreboot && run UserPreboot; pxefile_addr_r=0x43200000 ramdisk_addr_r=0x43300000 scriptaddr=0x43100000 serial#=02c000815a66276f stderr=serial,vga stdin=serial,usbkbd stdout=serial,vga Environment size: 898/131068 bytes => The loader variables are the following: loader> show LINES=24 autoboot_delay=10 bootfile=kernel console=uboot currdev=disk0s2: interpret=OK kernel=kernel kernelname=/boot/kernel/kernel loaddev=disk0s2: loader_conf_files=/boot/loader.conf /boot/loader.conf.local module_path=/boot/kernel;/boot/kernel;/boot/modules;/boot/dtb prompt=loader> twiddle_divisor=1 loader> The filesystem can be found: loader> ls / d .snap COPYRIGHT d bin d boot d dev d etc d lib d libexec d media d mnt d proc d rescue d root d sbin l sys d tmp d usr d var loader> ls boot boot d kernel d defaults d dtb d firmware d modules d zfs loader.efi boot1.efi boot1.efifat menu.rc.sample ubldr ubldr.bin beastie.4th brand.4th brand-fbsd.4th check-password.4th color.4th delay.4th frames.4th loader.4th loader.help logo-beastie.4th logo-beastiebw.4th menu.4th logo-fbsdbw.4th logo-orb.4th logo-orbbw.4th menu-commands.4th menusets.4th screen.4th shortcuts.4th support.4th version.4th loader.rc efi.4th loader> Other info from ubldr: loader> devinfo MMC Device 2 not found MMC Device 3 not found U-Boot devices: device info (0): cookie = 0xbbf3f0b8 type = 0x00000082 type = MMC blk size = 512 blk count = 30318592 device info (1): cookie = 0xbbf3f4c0 type = 0x00000082 type = MMC blk size = 512 blk count = 30535680 loader> sysinfo U-Boot system info: sys info: clkbus = 0 MHz clkcpu = 0 MHz bar = 0x00000000 --- start = 0x40000000 size = 0x80000000 type = DRAM --- loader> U-boot variables are found in ubldr: loader> ubenv show uboot.preboot=usb start; env exists bootfile || env set bootfile ubldr.bin; env exists SetupFatdev && run SetupFatdev; env exists UserPreboot && run UserPreboot; uboot.bootm_size=0xa000000 uboot.loaderdev=mmc 0 uboot.fatdev=mmc 0 uboot.fdtcontroladdr=bbf39b68 uboot.serial#=02c000815a66276f uboot.pxefile_addr_r=0x43200000 uboot.eth1addr=12:81:5a:66:27:6f uboot.api_address=bbf3f690 uboot.scriptaddr=0x43100000 uboot.ethaddr=02:81:5a:66:27:6f uboot.fdt_addr_r=0x43000000 uboot.stdin=serial,usbkbd uboot.baudrate=115200 uboot.ethact=ethernet@1c30000 uboot.bootcmd=run Fatboot uboot.kernel_addr_r=0x42000000 uboot.filesize=39e70 uboot.bootfile=ubldr.bin uboot.fdtfile=orangepi-plus-2e.dtb uboot.fileaddr=42000000 uboot.stdout=serial,vga uboot.ramdisk_addr_r=0x43300000 uboot.Fatboot=echo Booting from: ${fatdev} ${bootfile}; fatload ${fatdev} ${kernel_addr_r} ${bootfile} && bootelf || go ${kernel_addr_r}; uboot.console=ttyS0,115200 uboot.SetupFatdev=env exists fatdev || env set fatdev 'mmc 0'; uboot.ipaddr=192.168.0.200 uboot.stderr=serial,vga loader> Kernel and modules seem loaded... loader> lsmod 0x42200000: /boot/kernel/kernel (elf kernel, 0x9b456c) modules: aw_ccung.1 aw_ccu.1 aw_reset.1 a10hdmiaudio.1 a10hdmi.1 aw_thermal.1 aw_sid.1 axp81x.1 axp2xx.1 rsb.1 awusbphy.1 a10codec.1 ufs.1 krpc.1 cryptosoft.1 crypto.1 nfslockd.1 nfssvc.1 nfslock.1 ipsec.1 ether.1 zlib.1 aio.1 sysvshm.1 sysvsem.1 sysvmsg.1 acl_posix1e.1 acl_nfs4.1 kernel.1200030 cd9660.1 g_part.0 g_flashmap.0 pseudofs.1 procfs.1 nfscl.1 nfs.1 nfscommon.1 msdosfs.1 videomode.1 usb_quirk.1 ums.1 ukbd.1 uhub.1 usb.1 umass.1 midi.1 sound.5 random_device.1 random_harvestq.1 ofwbus.1 null.1 mmc.3 mii_bitbang.1 miibus.1 mem.1 ofw_iicbus.1 iicbus.1 iic.1 ofw_gpiobus.1 gpioc.1 gpiobus.1 fbd.1 ofw_regulator_bus.1 clk_fixed.1 ofw_clkbus.1 ahci.1 cam.1 Thanks, Mat From owner-freebsd-arm@freebsd.org Sun Apr 30 16:41:01 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8721CD577E9; Sun, 30 Apr 2017 16:41:01 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5409D1C40; Sun, 30 Apr 2017 16:41:01 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [IPv6:2a02:c7f:1e13:cf00:4f9:7787:8c3e:8b31] (unknown [IPv6:2a02:c7f:1e13:cf00:4f9:7787:8c3e:8b31]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id CBA114EB9A; Sun, 30 Apr 2017 16:40:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw under qemu-system-aarch64 on odroid-c2 under UbuntuMate : No valid device tree blob found! From: Andrew Turner In-Reply-To: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> Date: Sun, 30 Apr 2017 17:40:57 +0100 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> To: Mark Millard 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: Sun, 30 Apr 2017 16:41:01 -0000 > On 30 Apr 2017, at 12:02, Mark Millard wrote: >=20 > On 2017-Apr-30, at 1:57 AM, Andrew Turner = wrote: >=20 >>> On 30 Apr 2017, at 04:29, Mark Millard = wrote: >>> ... >>> acpi0: >>> acpi0: Power Button (fixed) >>> acpi0: Sleep Button (fixed) >>=20 >> ACPI is not fully supported on arm64. >=20 > Good to know. Thanks. >=20 > But the messages: >=20 > No valid device tree blob found! > WARNING! Trying to fire up the kernel, but no device tree blob found! >=20 > were well before the acpi0 messages so I'd expect > that the lack of a "device tree blob" is a separate, > earlier issue, likely to do with the content of: >=20 > FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw No, the device tree blob comes from UEFI. It seems the current UEFI only = provides the ACPI tables, and not a DTB. Andrew From owner-freebsd-arm@freebsd.org Sun Apr 30 17:15:51 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD1FAD573F2 for ; Sun, 30 Apr 2017 17:15:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8DE6EA0 for ; Sun, 30 Apr 2017 17:15:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25690 invoked from network); 30 Apr 2017 17:15:49 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Apr 2017 17:15:49 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sun, 30 Apr 2017 13:15:49 -0400 (EDT) Received: (qmail 27732 invoked from network); 30 Apr 2017 17:15:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Apr 2017 17:15:48 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 40CB3EC771C; Sun, 30 Apr 2017 10:15:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw under qemu-system-aarch64 on odroid-c2 under UbuntuMate : No valid device tree blob found! From: Mark Millard In-Reply-To: <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> Date: Sun, 30 Apr 2017 10:15:47 -0700 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> To: Andrew Turner 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: Sun, 30 Apr 2017 17:15:51 -0000 On 2017-Apr-30, at 9:40 AM, Andrew Turner = wrote: >> On 30 Apr 2017, at 12:02, Mark Millard = wrote: >>=20 >> On 2017-Apr-30, at 1:57 AM, Andrew Turner = wrote: >>=20 >>>> On 30 Apr 2017, at 04:29, Mark Millard = wrote: >>>> ... >>>> acpi0: >>>> acpi0: Power Button (fixed) >>>> acpi0: Sleep Button (fixed) >>>=20 >>> ACPI is not fully supported on arm64. >>=20 >> Good to know. Thanks. >>=20 >> But the messages: >>=20 >> No valid device tree blob found! >> WARNING! Trying to fire up the kernel, but no device tree blob found! >>=20 >> were well before the acpi0 messages so I'd expect >> that the lack of a "device tree blob" is a separate, >> earlier issue, likely to do with the content of: >>=20 >> FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw >=20 > No, the device tree blob comes from UEFI. It seems the current UEFI = only provides the ACPI tables, and not a DTB. So you are expecting that the older QEMU_EFI.fd I had used before provided some sort of fairly generic dtb (relative to qemu, fairly independent of the host that was running qemu). Interesting. Thanks again. It turns out that if I put the odroid-c2's dtb in where I can load it from the loader prompt (e.g., in /boot/dtb/ ) I get a little farther, although with notices for: Failed to start CPU 1 (1) Failed to start CPU 2 (2) Failed to start CPU 3 (3) pmu0: could not allocate resources device_attach: pmu0 attach returned 6 gpioled0: failed to map pin usb_needs_explore_all: no devclass The details of the sequence are: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds...=20 Type '?' for a list of commands, 'help' for more detailed help. OK load -t dtb /boot/dtb/meson64_odroidc2.dtb /boot/dtb/meson64_odroidc2.dtb size=3D0x746c OK boot ?[37m?[44mBooting...?[m Using DTB from loaded file '/boot/dtb/meson64_odroidc2.dtb'. 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 r317015M arm64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) VT: init without driver. Starting CPU 1 (1) Failed to start CPU 1 (1) Starting CPU 2 (2) Failed to start CPU 2 (2) Starting CPU 3 (3) Failed to start CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs arc4random: no preloaded entropy cache random: entropy device external interface kbd0 at kbdmux0 ofwbus0: psci0: on ofwbus0 gic0: mem = 0xc4301000-0xc4301fff,0xc4302000-0xc4303fff,0xc4304000-0xc4305fff,0xc43060= 00-0xc4307fff irq 18 on ofwbus0 gic0: pn 0x0, arch 0x0, rev 0x0, implementer 0x0 irqs 32 generic_timer0: irq 0,1,2,3 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 cpulist0: on ofwbus0 cpu0: on cpulist0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 pmu0: irq 4,5,6,7 on ofwbus0 pmu0: could not allocate resources device_attach: pmu0 attach returned 6 gpioled0: on ofwbus0 gpioled0: failed to map pin cryptosoft0: Timecounters tick every 1.000 msec usb_needs_explore_all: no devclass As of that it hangs. Using something like pine64_plus.dtb did not get far at all compared to the above. It is possible that for "-enable-kvm -cpu host" that the dtb needs to match the host machine's dtb. Still, it is not like what I thought I remembered from back in 2016-September: I did no dtb manipulations back then since I was unaware of the issue. The above is console output is for. . . qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -M virt \ -bios QEMU_EFI.fd -nographic \ -drive = format=3Draw,if=3Dnone,file=3DFreeBSD-12.0-CURRENT-arm64-aarch64-20170420-= r317181.raw,id=3Dhd0 \ -device virtio-blk-device,drive=3Dhd0 \ -device virtio-net-device,netdev=3Dnet0 \ -netdev user,id=3Dnet0 \ -smp cpus=3D4 based on: = http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upst= ream/1917/QEMU-AARCH64/RELEASE_CLANG35/QEMU_EFI.fd but this time based on my build of head -r317015 . I first got to the point of replicating what I'd reported for: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw then I added the 2 .dtb files to try loading. The Odroid-C2 one worked better on the Odroid-C2. It seems that qemu does not have a general dtb emulation capability. (No surprise there?) But I did not find anything saying what was required. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon May 1 01:31:07 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9ECF7D58716 for ; Mon, 1 May 2017 01:31:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5FD0AF12 for ; Mon, 1 May 2017 01:31:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23290 invoked from network); 1 May 2017 01:31:05 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 1 May 2017 01:31:05 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sun, 30 Apr 2017 21:31:05 -0400 (EDT) Received: (qmail 8158 invoked from network); 1 May 2017 01:31:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 1 May 2017 01:31:05 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 66802EC8FFF; Sun, 30 Apr 2017 18:31:04 -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: FYI: example "panic: ARM64TODO: reclaim_pv_chunk" on a Pine64+ 2GB with head -r317015 [mkimg okay; "cp -p" generates the bad context] Date: Sun, 30 Apr 2017 18:31:03 -0700 References: <4BC7E6BC-4BF9-4F5E-9851-E022AC9A3082@dsl-only.net> <51050A07-B951-45C0-82CE-73BB342F012E@dsl-only.net> <302D1255-4D34-4C1B-8F3A-9180A6AF8768@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org, FreeBSD Current In-Reply-To: <302D1255-4D34-4C1B-8F3A-9180A6AF8768@dsl-only.net> Message-Id: <7C5C4725-984C-4461-B76C-9A6BE052BA00@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 01:31:07 -0000 On 2017-Apr-27, at 10:26 PM, Mark Millard = wrote: > [As the text does not really follow from the earlier text > I'd sent directly I'm top posting a hypothesis about where > so much active memory came from to be so low in available > memory to get an reclaim_pv_chunk attempt.] >=20 > My hypothesis is that the "mdconfig -d"s from vm_copy_base > (from /usr/src/release/tools/vmimage.subr ) did not actually > release the memory resources involved (from vnode backed > mdconfig use): I watched with "vmstat 1" and "mdconfig -d" did release memory (including RAM) each time. > . . . > =46rom the prior top report for the failure, > partially repeated here: >=20 > . . . > Mem: 1618M Active, 17M Inact, 315M Wired, 204M Buf, 15M Free > Swap: 6144M Total, 34M Used, 6110M Free, 348K Out >=20 > PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND > 48988 root 4 31 0 651M 27048K 0K RUN 0 0:03 = 87.60% xz -T 0 = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT- > . . . >=20 > The combination 1618M Mem:Active but 34M Swap:Used > and 651M xz:SIZE but 27M xz:RES and 0K xz:SWAP just > seems very odd, like it should not happen. The 17M > Mem:Inact is odd for the context as well. (Mem:Wired, > Mem:Buf, and Mem:Free look normal.) >=20 > An alternate hypothesis would be the memory "leak" > is from mkimg not having it memory-use cleaned up. > This happens after vm_copy_base but before the cp/xz > sequence and is what produces vm.raw. mkimg also release its memory (including RAM) each time. But the later "cp -p" of the large vm.raw that I was producing ended up without leaving the free memory that is expected after it finished. I worked around the issue with (just a personal workaround that helps in other respects as well): Index: Makefile.vm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- Makefile.vm (revision 317015) +++ Makefile.vm (working copy) @@ -119,15 +119,20 @@ vm-install: .if defined(WITH_VMIMAGES) && !empty(WITH_VMIMAGES) mkdir -p ${DESTDIR}/vmimages -. for FORMAT in ${VMFORMATS} - cp -p ${VMBASE}.${FORMAT} \ - ${DESTDIR}/vmimages/${OSRELEASE}.${FORMAT} -. endfor . if defined(WITH_COMPRESSED_VMIMAGES) && = !empty(WITH_COMPRESSED_VMIMAGES) . for FORMAT in ${VMFORMATS} - # Don't keep the originals. There is a copy in ${.OBJDIR} if = needed. - ${XZ_CMD} ${DESTDIR}/vmimages/${OSRELEASE}.${FORMAT} + # Tradeoff "cp -p" property for less memory, I/O, and time use. + # Also: -3 got > 30 MiByte/sec effective (source file) for 32 = GiByte, mostly-zero image + # on a Pine64+ 2GB and used about 600 MiBytes of "active virtual = memory". The about 16 + # minutes was vastly faster than the "cp -p" --and the sha512 = and sha256 are vastly + # faster on the compressed file as well. + ${XZ_CMD} -T 0 -3 --stdout --memlimit-compress=3D50% -v = ${VMBASE}.${FORMAT} > ${DESTDIR}/vmimages/${OSRELEASE}.${FORMAT}.xz . endfor +. else +. for FORMAT in ${VMFORMATS} + cp -p ${VMBASE}.${FORMAT} \ + ${DESTDIR}/vmimages/${OSRELEASE}.${FORMAT} +. endfor . endif cd ${DESTDIR}/vmimages && sha512 ${OSRELEASE}* > \ ${DESTDIR}/vmimages/CHECKSUM.SHA512 and using WITH_COMPRESSED_VMIMAGES to avoid a "cp -p" based copy of the large file. Prior reports from capturing text: On 2017-Apr-27, at 7:31 PM, Mark Millard wrote: > [Another example panic. Again no dump. But I have what > a top -PCwaopid froze at this time.] >=20 > On 2017-Apr-27, at 4:22 PM, Mark Millard = wrote: >=20 >> Unfortunately for this FYI the attempt to produce a dump >> failed and so all the information that I have is what I >> first captured from the console output: a backtrace. >>=20 >> The context was head -r317015 on a Pine64+ 2GB. At the >> time I was experimenting with trying to build a vm.raw >> from my own build of FreeBSD. The (root) file system >> is on a USB SSD off of a powered USB hub. >>=20 >> panic: ARM64TODO: reclaim_pv_chunk >> cpuid =3D 1 >> time =3D 1493332968 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self_wrapper+0x28 >> pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc >> sp =3D 0xffff000083ba4f00 fp =3D 0xffff000083ba5110 >>=20 >> db_trace_self_wrapper() at vpanic+0x164 >> pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 >> sp =3D 0xffff000083ba5120 fp =3D 0xffff000083ba5190 >>=20 >> vpanic() at panic+0x4c >> pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc >> sp =3D 0xffff000083ba51a0 fp =3D 0xffff000083ba5220 >>=20 >> panic() at reclaim_pv_chunk+0x10 >> pc =3D 0xffff00000031d2fc lr =3D 0xffff00000061a234 >> sp =3D 0xffff000083ba5230 fp =3D 0xffff000083ba5230 >>=20 >> reclaim_pv_chunk() at get_pv_entry+0x240 >> pc =3D 0xffff00000061a234 lr =3D 0xffff000000616184 >> sp =3D 0xffff000083ba5240 fp =3D 0xffff000083ba5260 >>=20 >> get_pv_entry() at pmap_enter+0x694 >> pc =3D 0xffff000000616184 lr =3D 0xffff0000006156a0 >> sp =3D 0xffff000083ba5270 fp =3D 0xffff000083ba5300 >>=20 >> pmap_enter() at vm_fault_hold+0x28c >> pc =3D 0xffff0000006156a0 lr =3D 0xffff0000005b9740 >> sp =3D 0xffff000083ba5310 fp =3D 0xffff000083ba5460 >>=20 >> vm_fault_hold() at vm_fault+0x70 >> pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 >> sp =3D 0xffff000083ba5470 fp =3D 0xffff000083ba54a0 >>=20 >> vm_fault() at data_abort+0xe0 >> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >> sp =3D 0xffff000083ba54b0 fp =3D 0xffff000083ba5560 >>=20 >> data_abort() at handle_el1h_sync+0x70 >> pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 >> sp =3D 0xffff000083ba5570 fp =3D 0xffff000083ba5680 >>=20 >> handle_el1h_sync() at kern_select+0x9fc >> pc =3D 0xffff000000607870 lr =3D 0xffff00000037db3c >> sp =3D 0xffff000083ba5690 fp =3D 0xffff000083ba58f0 >>=20 >> kern_select() at sys_select+0x5c >> pc =3D 0xffff00000037db3c lr =3D 0xffff00000037dc58 >> sp =3D 0xffff000083ba5900 fp =3D 0xffff000083ba5930 >>=20 >> sys_select() at do_el0_sync+0xa48 >> pc =3D 0xffff00000037dc58 lr =3D 0xffff00000061b91c >> sp =3D 0xffff000083ba5940 fp =3D 0xffff000083ba5a70 >>=20 >> do_el0_sync() at handle_el0_sync+0x6c >> pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 >> sp =3D 0xffff000083ba5a80 fp =3D 0xffff000083ba5b90 >>=20 >> handle_el0_sync() at 0x4948c >> pc =3D 0xffff0000006079e8 lr =3D 0x000000000004948c >> sp =3D 0xffff000083ba5ba0 fp =3D 0x0000ffffffffd960 >=20 >=20 > This time I got to record from top: > (swap is on a swap partition) > (pid 49888's SIZE vs. RES and SWAP might be interesting) > (as might the Active figure) >=20 > last pid: 48988; load averages: 0.64, 0.44, 0.38 = = up 0+04:21:01 19:19:50 > 32 processes: 2 running, 30 sleeping > CPU 0: 13.2% user, 0.0% nice, 23.2% system, 0.3% interrupt, 63.3% = idle > CPU 1: 4.6% user, 0.0% nice, 23.9% system, 0.0% interrupt, 71.5% = idle > CPU 2: 2.1% user, 0.0% nice, 23.2% system, 0.0% interrupt, 74.8% = idle > CPU 3: 3.3% user, 0.0% nice, 23.8% system, 0.0% interrupt, 72.8% = idle > Mem: 1618M Active, 17M Inact, 315M Wired, 204M Buf, 15M Free > Swap: 6144M Total, 34M Used, 6110M Free, 348K Out >=20 > PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND > 48988 root 4 31 0 651M 27048K 0K RUN 0 0:03 = 87.60% xz -T 0 = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarc= h64.raw > 11983 root 1 22 0 5068K 0K 0K wait 3 0:00 = 0.00% make vm-image vm-install DESTDIR=3D/usr/obj/DESTDIRs/vmimage-aarch64= () > 11981 root 1 42 0 7320K 0K 1516K wait 1 0:00 = 0.00% sh = /root/sys_build_scripts.aarch64-host/make_noscript_aarch64_nodebug_clang_b= ootstrap-aarch64-host.sh vm-image vm-install=20 > 11980 root 1 20 0 6656K 1548K 0K select 0 0:02 = 0.00% [script] > 11977 root 1 30 0 7320K 0K 1516K wait 3 0:00 = 0.00% /bin/sh = /root/sys_build_scripts.aarch64-host/make_aarch64_nodebug_clang_bootstrap-= aarch64-host.sh vm-image vm-install DEST > 2694 root 1 20 0 8804K 2072K 0K CPU2 2 0:07 = 0.17% top -PCwaopid > 827 root 1 20 0 7320K 0K 360K wait 0 0:00 = 0.00% su () > 826 markmi 1 22 0 10372K 0K 1532K wait 3 0:00 = 0.00% su () > 820 markmi 1 24 0 7320K 0K 1516K wait 1 0:00 = 0.00% -sh () > 819 markmi 1 20 0 18416K 1152K 0K select 1 0:21 = 0.00% sshd: markmi@pts/1 (sshd) > 816 root 1 20 0 18416K 3276K 0K select 0 0:00 = 0.00% sshd: markmi [priv] (sshd) > 765 root 1 20 0 7320K 0K 224K wait 2 0:00 = 0.00% su () > 764 markmi 1 23 0 10372K 0K 1532K wait 0 0:00 = 0.00% su () > 758 markmi 1 31 0 7320K 0K 1516K wait 1 0:00 = 0.00% -sh () > 757 markmi 1 20 0 18416K 228K 904K select 3 0:01 = 0.01% sshd: markmi@pts/0 (sshd) > 754 root 1 25 0 18416K 3276K 0K select 1 0:00 = 0.00% sshd: markmi [priv] (sshd) > 746 root 1 27 0 7320K 1532K 0K ttyin 0 0:00 = 0.00% -sh (sh) > 745 root 1 20 0 10372K 0K 1532K wait 1 0:00 = 0.00% login [pam] () > 700 root 1 20 0 6948K 0K 168K nanslp 1 0:00 = 0.00% /usr/sbin/cron -s () > 696 smmsp 1 20 0 10460K 0K 184K pause 0 0:00 = 0.00% sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue = () > 693 root 1 20 0 10460K 1392K 0K select 1 0:00 = 0.03% sendmail: accepting connections (sendmail) > 690 root 1 20 0 15800K 968K 0K select 2 0:00 = 0.00% /usr/sbin/sshd > 661 root 1 20 0 6656K 344K 0K select 2 0:01 = 0.00% /usr/sbin/powerd > 658 root 2 20 0 12788K 12672K 0K select 0 0:02 = 0.01% /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f = /var/db/ntpd.drift > 620 root 32 52 0 6384K 1100K 0K rpcsvc 1 0:00 = 0.00% nfsd: server (nfsd) > 619 root 1 52 0 6384K 704K 0K select 1 0:00 = 0.00% nfsd: master (nfsd) > 617 root 1 20 0 6684K 688K 0K select 1 0:00 = 0.00% /usr/sbin/mountd -r > 478 root 1 20 0 6676K 596K 0K select 3 0:00 = 0.00% /usr/sbin/rpcbind > 469 root 1 20 0 6680K 572K 0K select 2 0:00 = 0.00% /usr/sbin/syslogd -s > 396 root 1 20 0 9580K 32K 0K select 0 0:00 = 0.00% /sbin/devd > 308 _dhcp 1 20 0 6800K 532K 0K select 2 0:00 = 0.00% dhclient: awg0 (dhclient) > 307 root 1 52 0 6800K 424K 0K select 2 0:00 = 0.00% dhclient: awg0 [priv] (dhclient) >=20 > And here is the backtrace: >=20 > timeout stopping cpus > panic: ARM64TODO: reclaim_pv_chunk > cpuid =3D 0 > time =3D 1493345992 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc > sp =3D 0xffff000083d301d0 fp =3D 0xffff000083d303e0 >=20 > db_trace_self_wrapper() at vpanic+0x164 > pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 > sp =3D 0xffff000083d303f0 fp =3D 0xffff000083d30460 >=20 > vpanic() at panic+0x4c > pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc > sp =3D 0xffff000083d30470 fp =3D 0xffff000083d304f0 >=20 > panic() at reclaim_pv_chunk+0x10 > pc =3D 0xffff00000031d2fc lr =3D 0xffff00000061a234 > sp =3D 0xffff000083d30500 fp =3D 0xffff000083d30500 >=20 > reclaim_pv_chunk() at get_pv_entry+0x240 > pc =3D 0xffff00000061a234 lr =3D 0xffff000000616184 > sp =3D 0xffff000083d30510 fp =3D 0xffff000083d30530 >=20 > get_pv_entry() at pmap_enter+0x694 > pc =3D 0xffff000000616184 lr =3D 0xffff0000006156a0 > sp =3D 0xffff000083d30540 fp =3D 0xffff000083d305d0 >=20 > pmap_enter() at vm_fault_hold+0x28c > pc =3D 0xffff0000006156a0 lr =3D 0xffff0000005b9740 > sp =3D 0xffff000083d305e0 fp =3D 0xffff000083d30730 >=20 > vm_fault_hold() at vm_fault+0x70 > pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 > sp =3D 0xffff000083d30740 fp =3D 0xffff000083d30770 >=20 > vm_fault() at data_abort+0xe0 > pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 > sp =3D 0xffff000083d30780 fp =3D 0xffff000083d30830 >=20 > data_abort() at handle_el0_sync+0x6c > pc =3D 0xffff00000061ad94 lr =3D 0xffff0000006079e8 > sp =3D 0xffff000083d30840 fp =3D 0xffff000083d30950 >=20 > handle_el0_sync() at 0x400a3de4 > pc =3D 0xffff0000006079e8 lr =3D 0x00000000400a3de4 > sp =3D 0xffff000083d30960 fp =3D 0x0000ffffbfdfcd30 >=20 > KDB: enter: panic > [ thread pid 48988 tid 100230 ] > Stopped at kdb_enter+0x44: undefined d4200000 >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Tue May 2 01:22:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A112CD58F18 for ; Tue, 2 May 2017 01:22:24 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6631D648 for ; Tue, 2 May 2017 01:22:23 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qt0-x229.google.com with SMTP id c45so101106450qtb.1 for ; Mon, 01 May 2017 18:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=to:from:subject:message-id:date:user-agent:mime-version; bh=j7jtdyJT2iPHThMm/nD+BU1yZ9wx6NMHqOOYVgp6xII=; b=d02OSgwUiRrKT5OE5ZQ2hcBupHOsmPshADxq39tiessAt3jaCRnCKQnriBdGavys0H wf8SSuxb+m0mQtocD2NIzH1ZU4ULN8lv8GY8Wc6d3VVlMsUx0qJgqlM9O0xAbS9dL22v SNjK2uCy5k+83V8ToOaqO2LViqTqwExU3tYZs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=j7jtdyJT2iPHThMm/nD+BU1yZ9wx6NMHqOOYVgp6xII=; b=L+gJiuWKziHc5p7NHjaEfKcJ+JhAkU+E7oe1RwceVLU5EEQpJc2aAqZyvxQiMytQNu 2s8MnbppDfVYrg/iKuJKooEhEMRyULdBtHvZ0ePh582LXC+e2UDxIg5MuuFE11glGhBK 8dkfYee/F9zdrfd55LR2MpeHzh6+uw0DS3bPqNLfm6QSSVgIdm2JOlRq8rM9KrplhyYG jsNcE9f81k/+neQAnIboGvUG9p5XVzOFFLq0UqS0ddJW8ZXvBWOaeylHOIkZ6usOnb/I 4PQBVotIHf+UolCIMiJfMznzGWLYlhz0PZTkXZb1PzpTu4NIWUo6D692kg6/8eTXUESK KObw== X-Gm-Message-State: AN3rC/7Zvx8AB9OxN7wNGZTIxCZmcvzjRL9JoNqyRyf9Y4/RxmOvm4Cm Eh1BZDc+CUDjOTyv X-Received: by 10.200.37.70 with SMTP id 6mr25935923qtn.130.1493688142248; Mon, 01 May 2017 18:22:22 -0700 (PDT) Received: from ?IPv6:2804:54:19ef:cc00:e5c4:231:226:642d? ([2804:54:19ef:cc00:e5c4:231:226:642d]) by smtp.googlemail.com with ESMTPSA id s125sm6565825qkh.61.2017.05.01.18.22.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 May 2017 18:22:20 -0700 (PDT) To: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Subject: lock when building llvm37 on RPI3 Message-ID: <0b4b8a6f-f008-4892-a7c1-73fab2a79030@bsd.com.br> Date: Mon, 1 May 2017 22:22:11 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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, 02 May 2017 01:22:24 -0000 Hello guys. To those who are using ARM64, have you compiled large software like llvm? I'm trying to compile llvm37 but, at first try, the system spent more than an hour on [42/3588] when compiling llvm37 as a dependency of webcamd. Then, I reset and it passed quickly from 42 and is now on [148/3588]. I also faced two crashes when I was trying to do this for ssh, but unfortunately I had no monitor connected to RPI3. I am using head revision 317063. []'s -Otacilio From owner-freebsd-arm@freebsd.org Tue May 2 08:55: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 2C787D5ADE5 for ; Tue, 2 May 2017 08:55:17 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 78D4E9C5 for ; Tue, 2 May 2017 08:55:15 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 8d9fe6bd; Tue, 2 May 2017 10:55:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=kfUtmJr7Hnad8PEU1CkBIDg2Hcs=; b=jPANVHFj6b3ZuQYAAi2MBXTxm3CD V0sbBiDSn6OMUjdf8vU8BdefLpbULVtjwz2Og0mO9b8wDHJp4AnyA1nBv2FNF0Ms mZygSXgrXAuCTeOfce7Vs8DuBIRsXPFMPnuBHa8J+StyMtnTF8TzK0NQqfJ6MrrN 6ApRBqAS2A+o6J4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=X10MNfRokfCjEwasflfIbyxe0IU/euneIzeB1r9xW6elY4Bfw45ov6sT xV4b/OY+67B6kJIPltMglM/HjoxP2C3Qrqvq/iM7ob6UF4TYSHAAVTNYUoGOc92c 9hpm77KnJQ98T6WAlHmeTZs2eYQsqTRo2+JdVdb0nBlQzfK7M6Y= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 8c170188 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 2 May 2017 10:55:13 +0200 (CEST) Date: Tue, 2 May 2017 10:55:07 +0200 From: Emmanuel Vadot To: aggaz Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD 12-CURRENT on OrangePi One Message-Id: <20170502105507.4c51a7323bd01903e402f551@bidouilliste.com> In-Reply-To: <9e04f3cf-ddce-1b53-b9d6-2fe05ad1cc25@paranoici.org> References: <9e04f3cf-ddce-1b53-b9d6-2fe05ad1cc25@paranoici.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 08:55:17 -0000 On Sun, 30 Apr 2017 12:27:04 +0200 aggaz wrote: > Dear list, > > as I previously wrote, I am trying to use FreeBSD 12-CURRENT on OrangePi > One by using crochet. > > One problem is that there are no dtb files available specific for this > board. There is one in sys/gnu/dts, I was sure that I added it to the list of DTS we compile but ... > Now I compared two dtb files for the same SoC (H3): one for NanoPi Neo > (/boot/dtb/nanopi-neo.dtb) and one for OrangePi Plus 2E > (/boot/dtb/orangepi-plus-2e.dtb). > > Both makes the board boot fine without issues, but: > > 1) dtb file for NanoPi Neo makes the network interface available and > working, but not the USB port. > > 2) dtb file for OrangePi Plus 2E makes the USB port available and > working, but not the network interface. Please note that ethernet DTS bindings aren't standardized yet and since I don't want us to heavily patches the DTS or derive to much from the Linux one if I add the OrangePi One DTS to the build it will probably be without ethernet support. Anyway, I have one somewhere with USB and ethernet support, I'll look to commit/share that soon. > > At this point I don't really know what I can do to make both interfaces > working at the same time, and I am writing this to ask you some suggestions. > > Any idea would be greatly appreciated. > > Regards > Aggaz > _______________________________________________ > 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" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue May 2 08:56:52 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D601D5AE84 for ; Tue, 2 May 2017 08:56:52 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EC270B0C for ; Tue, 2 May 2017 08:56:51 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 2444d861; Tue, 2 May 2017 10:50:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=1HXVgx54ORNsQZg8Q/y61D6lzuM=; b=Gv3bbd3AUD9TYoB5hEd+0d29lqte XVPj2Rb8ag+aIlXRh9XIkhm0L6yEEJHTKRFL71X1WvOD39Z0lrwQesd9sga31cEe zrsYcjWbWbKAR85OxozyvEqdRZGhX7K3K4hmu+YUerPYSRBxj5YmC0yO2sZOp8Zs 71UZjAIpkLLPai8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=dp8SiHRdSoqGrN/0qEz5/DpdZl9XXpEdMLn1JOj4atGC0OSqn4FkcnsG htzbIRoFtFEC+XOl46CXGgJOvywGcLz+Oes7YDhzrpQwAU63HqkHjE3+Nom7FIIu /yNp0F+dqtyABwJ+3XHw7cfQ4Zvj09SB1PAL1NZroen3UM80Jak= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 5c4dd2cf TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 2 May 2017 10:50:09 +0200 (CEST) Date: Tue, 2 May 2017 10:50:07 +0200 From: Emmanuel Vadot To: mattia.rossi.mate@gmail.com Cc: ARM Subject: Re: OrangePi-Plus-2 boot process hangs in ubldr.bin Message-Id: <20170502105007.0424f8cb7c8021951bf04495@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 08:56:52 -0000 On Sun, 30 Apr 2017 13:07:23 +0200 Mattia Rossi wrote: > Hi all, Hello, > I've tried to upgrade u-boot on the OrangePi-Plus-2 (not the 2e) from > mainline u-boot and on the outside it looks fine. When you say mainline, what exact version did you took ? I assume you took some patches also as it seems that your u-boot have API support. > U-boot loads, and it boots ubldr.bin. > > I'm using the orangepi-plus-2e.dtb as it has been working well for this > board before (It all used to work). > > Now ubldr can't boot the kernel though, and I don't know why. I've > rebuilt ubldr, world and kernel from svn. Revision number is 317594 > > Any help would be appreciated > > The output before it stops is: > > U-Boot SPL 2017.05-rc2-00061-g12af9399e7 (Apr 25 2017 - 19:27:44) > DRAM: 2048 MiB > Trying to boot from MMC1 > > > U-Boot 2017.05-rc2-00061-g12af9399e7 (Apr 25 2017 - 19:27:44 +0200) > Allwinner Technology > > CPU: Allwinner H3 (SUN8I 1680) > Model: Xunlong Orange Pi Plus 2E > I2C: ready > DRAM: 2 GiB > MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 > In: serial > Out: serial > Err: serial > Net: phy interface7 > eth0: ethernet@1c30000 > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > USB2: USB EHCI 1.00 > USB3: USB OHCI 1.0 > USB4: USB EHCI 1.00 > USB5: USB OHCI 1.0 > scanning bus 0 for devices... 1 USB Device(s) found > scanning bus 2 for devices... 1 USB Device(s) found > scanning bus 4 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > Booting from: mmc 0 ubldr.bin > reading ubldr.bin > 237168 bytes read in 34 ms (6.7 MiB/s) > ## No elf image at address 0x42000000 > ## Starting application at 0x42000000 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @0xbbf3f690 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (Sat Apr 29 19:16:42 CEST 2017 root@freebsd101) > > DRAM: 2048MB > MMC Device 2 not found > MMC Device 3 not found > Number of U-Boot devices: 2 > U-Boot env: loaderdev='mmc 0' > Found U-Boot device: disk > Checking unit=0 slice= partition=... good. > Booting from disk0s2: > /boot/kernel/kernel data=0x6a82c0+0x1a7d40 syms=[0x4+0xba030+0x4+0xaa532] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > /boot/dtb/orangepi-plus-2e.dtb size=0x6326 > Loaded DTB from file 'orangepi-plus-2e.dtb'. > Kernel entry at 0x42200100... > Kernel args: (null) This is probably a cache problem, the u-boot from ports (using imp@ branch on github) do take care of that. > > The u-boot environment looks like this: > > => printenv > Fatboot=echo Booting from: ${fatdev} ${bootfile}; fatload ${fatdev} > ${kernel_addr_r} ${bootfile} && bootelf || go ${kernel_addr_r}; > SetupFatdev=env exists fatdev || env set fatdev 'mmc 0'; > api_address=bbf3f690 > baudrate=115200 > bootcmd=run Fatboot > bootfile=ubldr.bin > bootm_size=0xa000000 > console=ttyS0,115200 > eth1addr=12:81:5a:66:27:6f > ethact=ethernet@1c30000 > ethaddr=02:81:5a:66:27:6f > fatdev=mmc 0 > fdt_addr_r=0x43000000 > fdtcontroladdr=bbf39b68 > fdtfile=orangepi-plus-2e.dtb > ipaddr=192.168.0.200 > kernel_addr_r=0x42000000 > loaderdev=mmc 0 > preboot=usb start; env exists bootfile || env set bootfile ubldr.bin; > env exists SetupFatdev && run SetupFatdev; env exists UserPreboot && run > UserPreboot; > pxefile_addr_r=0x43200000 > ramdisk_addr_r=0x43300000 > scriptaddr=0x43100000 > serial#=02c000815a66276f > stderr=serial,vga > stdin=serial,usbkbd > stdout=serial,vga > > Environment size: 898/131068 bytes > => > > > The loader variables are the following: > > loader> show > LINES=24 > autoboot_delay=10 > bootfile=kernel > console=uboot > currdev=disk0s2: > interpret=OK > kernel=kernel > kernelname=/boot/kernel/kernel > loaddev=disk0s2: > loader_conf_files=/boot/loader.conf /boot/loader.conf.local > module_path=/boot/kernel;/boot/kernel;/boot/modules;/boot/dtb > prompt=loader> > twiddle_divisor=1 > loader> > > > The filesystem can be found: > > loader> ls > / > d .snap > COPYRIGHT > d bin > d boot > d dev > d etc > d lib > d libexec > d media > d mnt > d proc > d rescue > d root > d sbin > l sys > d tmp > d usr > d var > loader> ls boot > boot > d kernel > d defaults > d dtb > d firmware > d modules > d zfs > loader.efi > boot1.efi > boot1.efifat > menu.rc.sample > ubldr > ubldr.bin > beastie.4th > brand.4th > brand-fbsd.4th > check-password.4th > color.4th > delay.4th > frames.4th > loader.4th > loader.help > logo-beastie.4th > logo-beastiebw.4th > menu.4th > logo-fbsdbw.4th > logo-orb.4th > logo-orbbw.4th > menu-commands.4th > menusets.4th > screen.4th > shortcuts.4th > support.4th > version.4th > loader.rc > efi.4th > loader> > > Other info from ubldr: > > loader> devinfo > MMC Device 2 not found > MMC Device 3 not found > U-Boot devices: > device info (0): > cookie = 0xbbf3f0b8 > type = 0x00000082 > type = MMC > blk size = 512 > blk count = 30318592 > > device info (1): > cookie = 0xbbf3f4c0 > type = 0x00000082 > type = MMC > blk size = 512 > blk count = 30535680 > > loader> sysinfo > U-Boot system info: > sys info: > clkbus = 0 MHz > clkcpu = 0 MHz > bar = 0x00000000 > --- > start = 0x40000000 > size = 0x80000000 > type = DRAM > --- > loader> > > U-boot variables are found in ubldr: > > loader> ubenv show > uboot.preboot=usb start; env exists bootfile || env set bootfile > ubldr.bin; env exists SetupFatdev && run SetupFatdev; env exists > UserPreboot && run UserPreboot; > uboot.bootm_size=0xa000000 > uboot.loaderdev=mmc 0 > uboot.fatdev=mmc 0 > uboot.fdtcontroladdr=bbf39b68 > uboot.serial#=02c000815a66276f > uboot.pxefile_addr_r=0x43200000 > uboot.eth1addr=12:81:5a:66:27:6f > uboot.api_address=bbf3f690 > uboot.scriptaddr=0x43100000 > uboot.ethaddr=02:81:5a:66:27:6f > uboot.fdt_addr_r=0x43000000 > uboot.stdin=serial,usbkbd > uboot.baudrate=115200 > uboot.ethact=ethernet@1c30000 > uboot.bootcmd=run Fatboot > uboot.kernel_addr_r=0x42000000 > uboot.filesize=39e70 > uboot.bootfile=ubldr.bin > uboot.fdtfile=orangepi-plus-2e.dtb > uboot.fileaddr=42000000 > uboot.stdout=serial,vga > uboot.ramdisk_addr_r=0x43300000 > uboot.Fatboot=echo Booting from: ${fatdev} ${bootfile}; fatload > ${fatdev} ${kernel_addr_r} ${bootfile} && bootelf || go ${kernel_addr_r}; > uboot.console=ttyS0,115200 > uboot.SetupFatdev=env exists fatdev || env set fatdev 'mmc 0'; > uboot.ipaddr=192.168.0.200 > uboot.stderr=serial,vga > loader> > > Kernel and modules seem loaded... > > loader> lsmod > 0x42200000: /boot/kernel/kernel (elf kernel, 0x9b456c) > modules: aw_ccung.1 aw_ccu.1 aw_reset.1 a10hdmiaudio.1 a10hdmi.1 > aw_thermal.1 aw_sid.1 axp81x.1 axp2xx.1 rsb.1 awusbphy.1 a10codec.1 > ufs.1 krpc.1 cryptosoft.1 crypto.1 nfslockd.1 nfssvc.1 nfslock.1 ipsec.1 > ether.1 zlib.1 aio.1 sysvshm.1 sysvsem.1 sysvmsg.1 acl_posix1e.1 > acl_nfs4.1 kernel.1200030 cd9660.1 g_part.0 g_flashmap.0 pseudofs.1 > procfs.1 nfscl.1 nfs.1 nfscommon.1 msdosfs.1 videomode.1 usb_quirk.1 > ums.1 ukbd.1 uhub.1 usb.1 umass.1 midi.1 sound.5 random_device.1 > random_harvestq.1 ofwbus.1 null.1 mmc.3 mii_bitbang.1 miibus.1 mem.1 > ofw_iicbus.1 iicbus.1 iic.1 ofw_gpiobus.1 gpioc.1 gpiobus.1 fbd.1 > ofw_regulator_bus.1 clk_fixed.1 ofw_clkbus.1 ahci.1 cam.1 > > Thanks, > > Mat > > _______________________________________________ > 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" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue May 2 09:53:51 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4DA3FD5AE29 for ; Tue, 2 May 2017 09:53:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 006501B1F for ; Tue, 2 May 2017 09:53:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12720 invoked from network); 2 May 2017 09:53:43 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 May 2017 09:53:43 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 02 May 2017 05:53:43 -0400 (EDT) Received: (qmail 24095 invoked from network); 2 May 2017 09:53:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 May 2017 09:53:43 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C98FDEC7E18; Tue, 2 May 2017 02:53:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots] From: Mark Millard In-Reply-To: <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> Date: Tue, 2 May 2017 02:53:42 -0700 Cc: freebsd-arm , FreeBSD Current , Tom Vijlbrief , "O. Hartmann" Content-Transfer-Encoding: quoted-printable Message-Id: <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> To: Andrew Turner X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 09:53:51 -0000 On 2017-Apr-30, at 10:15 AM, Mark Millard wrote: > On 2017-Apr-30, at 9:40 AM, Andrew Turner = wrote: >=20 >>> On 30 Apr 2017, at 12:02, Mark Millard = wrote: >>> . . . >>=20 >> No, the device tree blob comes from UEFI. It seems the current UEFI = only provides the ACPI tables, and not a DTB. >=20 > So you are expecting that the older QEMU_EFI.fd I had > used before provided some sort of fairly generic dtb > (relative to qemu, fairly independent of the host > that was running qemu). Interesting. Thanks again. > . . . > qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -M virt \ > -bios QEMU_EFI.fd -nographic \ > -drive = format=3Draw,if=3Dnone,file=3DFreeBSD-12.0-CURRENT-arm64-aarch64-20170420-= r317181.raw,id=3Dhd0 \ > -device virtio-blk-device,drive=3Dhd0 \ > -device virtio-net-device,netdev=3Dnet0 \ > -netdev user,id=3Dnet0 \ > -smp cpus=3D4 >=20 > based on: >=20 > = http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upst= ream/1917/QEMU-AARCH64/RELEASE_CLANG35/QEMU_EFI.fd Using the following instead lead to booting all the way and being able to login: = https://releases.linaro.org/components/kernel/uefi-linaro/16.02/release/qe= mu64/QEMU_EFI.fd So you were definitely correct. > but this time based on my build of head -r317015 . This combination seemed more stable than the one from back in 2016-Sept. I strongly expect that the official snapshot would boot based on this alternate QEMU_EFI.fd as well, but I've not tried that combination. The boot still gets: usb_needs_explore_all: no devclass during the boot but it does not hang after that message. I have not gotten networking going in FreeBSD in the quick try that I made. So I still do not have a /usr/src in place to try with a buildworld buildkernel . Here is a boot log: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 6 block devices.......*. done ZFS found no pools UFS found 1 partition Consoles: EFI console =20 Command line arguments: loader.efi Image base: 0x79c13000 EFI version: 2.60 EFI Firmware: EDK II (rev 1.00) FreeBSD/arm64 EFI loader, Revision 1.1 EFI boot environment Loading /boot/defaults/loader.conf /boot/kernel/kernel text=3D0x7ba068 data=3D0x9e6f8+0x39c3fe = syms=3D[0x8+0x103b60+0x8+0xf8a79] /boot/entropy size=3D0x1000 Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB provided by EFI at 0x7ffdd000. 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 r317015M arm64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) VT: init without driver. Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: unblocking device. random: entropy device external interface kbd0 at kbdmux0 ofwbus0: simplebus0: on ofwbus0 clk_fixed0: on ofwbus0 psci0: on ofwbus0 gic0: mem = 0x8000000-0x800ffff,0x8010000-0x801ffff on ofwbus0 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 288 gicv2m0: mem = 0x8020000-0x8020fff on gic0 generic_timer0: irq 34,35,36,37 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 virtio_mmio0: mem 0xa000000-0xa0001ff irq 0 on = ofwbus0 virtio_mmio1: mem 0xa000200-0xa0003ff irq 1 on = ofwbus0 virtio_mmio2: mem 0xa000400-0xa0005ff irq 2 on = ofwbus0 virtio_mmio3: mem 0xa000600-0xa0007ff irq 3 on = ofwbus0 virtio_mmio4: mem 0xa000800-0xa0009ff irq 4 on = ofwbus0 virtio_mmio5: mem 0xa000a00-0xa000bff irq 5 on = ofwbus0 virtio_mmio6: mem 0xa000c00-0xa000dff irq 6 on = ofwbus0 virtio_mmio7: mem 0xa000e00-0xa000fff irq 7 on = ofwbus0 virtio_mmio8: mem 0xa001000-0xa0011ff irq 8 on = ofwbus0 virtio_mmio9: mem 0xa001200-0xa0013ff irq 9 on = ofwbus0 virtio_mmio10: mem 0xa001400-0xa0015ff irq 10 on = ofwbus0 virtio_mmio11: mem 0xa001600-0xa0017ff irq 11 on = ofwbus0 virtio_mmio12: mem 0xa001800-0xa0019ff irq 12 on = ofwbus0 virtio_mmio13: mem 0xa001a00-0xa001bff irq 13 on = ofwbus0 virtio_mmio14: mem 0xa001c00-0xa001dff irq 14 on = ofwbus0 virtio_mmio15: mem 0xa001e00-0xa001fff irq 15 on = ofwbus0 virtio_mmio16: mem 0xa002000-0xa0021ff irq 16 on = ofwbus0 virtio_mmio17: mem 0xa002200-0xa0023ff irq 17 on = ofwbus0 virtio_mmio18: mem 0xa002400-0xa0025ff irq 18 on = ofwbus0 virtio_mmio19: mem 0xa002600-0xa0027ff irq 19 on = ofwbus0 virtio_mmio20: mem 0xa002800-0xa0029ff irq 20 on = ofwbus0 virtio_mmio21: mem 0xa002a00-0xa002bff irq 21 on = ofwbus0 virtio_mmio22: mem 0xa002c00-0xa002dff irq 22 on = ofwbus0 virtio_mmio23: mem 0xa002e00-0xa002fff irq 23 on = ofwbus0 virtio_mmio24: mem 0xa003000-0xa0031ff irq 24 on = ofwbus0 virtio_mmio25: mem 0xa003200-0xa0033ff irq 25 on = ofwbus0 virtio_mmio26: mem 0xa003400-0xa0035ff irq 26 on = ofwbus0 virtio_mmio27: mem 0xa003600-0xa0037ff irq 27 on = ofwbus0 virtio_mmio28: mem 0xa003800-0xa0039ff irq 28 on = ofwbus0 virtio_mmio29: mem 0xa003a00-0xa003bff irq 29 on = ofwbus0 virtio_mmio30: mem 0xa003c00-0xa003dff irq 30 on = ofwbus0 vtnet0: on virtio_mmio30 vtnet0: Ethernet address: 52:54:00:12:34:56 virtio_mmio31: mem 0xa003e00-0xa003fff irq 31 on = ofwbus0 vtblk0: on virtio_mmio31 vtblk0: 32768MB (67110465 512 byte sectors) pcib0: mem 0x3f000000-0x3fffffff on = ofwbus0 pci0: on pcib0 uart0: mem 0x9000000-0x9000fff irq 33 on = ofwbus0 uart0: console (9600,n,8,1) cpulist0: on ofwbus0 cpu0: on cpulist0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 cryptosoft0: Timecounters tick every 10.000 msec usb_needs_explore_all: no devclass Release APs CPU 0: ARM Cortex-A53 r0p4 affinity: 0 Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <0> Processor Features 0 =3D Processor Features 1 =3D <0> Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> Memory Model Features 1 =3D <> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> Debug Features 1 =3D <0> Auxiliary Features 0 =3D <0> Auxiliary Features 1 =3D <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 Trying to mount root from ufs:/dev/ufs/rootfs [rw]... warning: no time-of-day clock registered, system time will not be set = accurately Setting hostuuid: 5f6ed2d1-2dcc-11e7-b81e-f171534e5634. Setting hostid: 0x9f2fff5d. Starting file system checks: /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/rootfs: clean, 6154717 free (4485 frags, 768779 blocks, 0.1% = fragmentation) Mounting local filesystems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat Setting hostname: ODC2FBSD. Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATT= ACH,CACHED Feeding entropy: . Starting Network: lo0 vtnet0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 inet 127.0.0.1 netmask 0xff000000=20 groups: lo=20 nd6 options=3D21 vtnet0: flags=3D8802 metric 0 mtu 1500 options=3D80028 ether 52:54:00:12:34:56 media: Ethernet 10Gbase-T status: active nd6 options=3D29 Starting devd. Starting Network: vtnet0. vtnet0: flags=3D8802 metric 0 mtu 1500 options=3D80028 ether 52:54:00:12:34:56 media: Ethernet 10Gbase-T status: active nd6 options=3D29 add host 127.0.0.1: gateway lo0 fib 0: route already in table add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Creating and/or trimming log files. Starting syslogd. No core dumps found. Clearing /tmp (X related). Updating motd:. Mounting late filesystems:. Starting sendmail_submit. Starting sendmail_msp_queue. Starting cron. Starting background file system checks in 60 seconds. Sun Apr 30 18:41:18 UTC 2017 FreeBSD/arm64 (ODC2FBSD) (ttyu0) login:=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue May 2 10:16: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 BBAECD576F8 for ; Tue, 2 May 2017 10:16:25 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.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 8EFE6CE1 for ; Tue, 2 May 2017 10:16:25 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 64D0D20A07 for ; Tue, 2 May 2017 06:16:24 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Tue, 02 May 2017 06:16:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=jOpxrSFJqMsMUTrQcS pva04kES5Uv9knVuaQtumWuw4=; b=Ct82RpMDr5aSk5uv7GHdw4EP53ttNs6b7b W6u+8lfixzqlhVdjqbdfSIX0iifB7qgZOfm74yz6xhbAj2fdfYEdTYoempQfiCR3 Wi5m1ltwDrq8utdskjPy1Lvf7ISvTWfkjOACGrtHpVxmvW8KBaCrOvGIl7c66NN5 dyMH6/nHKkbVuOIHbc/vrTtYDVQS0OTwaSmiyKJRqDd2HyWY0T7xvspoHzdgfPMI 1WywFVTSgeXd3rWWHO+Zd30Wscy7T/1zYR0TK9umW2TMf3W0BoiDRdAYLX7h0Vg9 +38DWdeeTU8xUz9S0suZ1z3jHGqaPGbI7DYh+Tm9HJ3tRG1hM90g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=jOpxrSFJqMsMUTrQcSpva04kES5Uv9knVuaQtumWuw4=; b=a9Z64VhD zT8bS0lka8oqwMvKhoPg3mXrTx4hb9xCJBeCf25vCPIV/6TWSgv8b1K7+hKjfRX4 pNUKtTSkJIyYKyOTtvnZzTMjlRBWm/PY0QfYrfUg39PwB0LC26dKfmzTT2TkUIfD kj47fKs8bdwcqDqIrI/fHthWA1+qhFGvCxRE2b1PKnrQp8Z914peUOdYmDOFAdWe zFQPDvX+5fr420NwkfpcIhbqhvfhcGWzECPeZGdDHM+cTj70hyNEGPzMxQYM+H8Y ikahKRaA+npteAAJjnz8r7ZAsl4BlICrpTyrqCqWfkSNXZgKEhFxklTRKkwwoRyt Je68Vl1RPwPpjw== X-ME-Sender: X-Sasl-enc: 9VKRBZYJ5RJGsjZtSBmdC4Ai7NUNTkJ2y8JB5op+Kcpk 1493720184 Received: from [192.168.1.230] (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id 08313241E3 for ; Tue, 2 May 2017 06:16:23 -0400 (EDT) Subject: Re: lock when building llvm37 on RPI3 To: freebsd-arm@freebsd.org References: <0b4b8a6f-f008-4892-a7c1-73fab2a79030@bsd.com.br> From: tech-lists Message-ID: <4085737d-af52-3f21-c593-3be249b59d46@zyxst.net> Date: Tue, 2 May 2017 11:16:20 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <0b4b8a6f-f008-4892-a7c1-73fab2a79030@bsd.com.br> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB 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, 02 May 2017 10:16:25 -0000 On 02/05/2017 02:22, Otacílio wrote: > To those who are using ARM64, have you compiled large software like > llvm? I'm trying to compile llvm37 but, at first try, the system spent > more than an hour on [42/3588] when compiling llvm37 as a dependency of > webcamd. Then, I reset and it passed quickly from 42 and is now on > [148/3588]. I also faced two crashes when I was trying to do this for > ssh, but unfortunately I had no monitor connected to RPI3. I am using > head revision 317063. Hi, 1. did you install ccache first? It makes a really big difference. And then tell /etc/make.conf to use it? 2. have you mounted /usr/obj onto separate hardware, like a usb stick? 3. is /tmp also offloaded similarly? -- J. From owner-freebsd-arm@freebsd.org Tue May 2 10:37: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 E1FC1D57E91 for ; Tue, 2 May 2017 10:37:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9EFE0AB6 for ; Tue, 2 May 2017 10:37:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4070 invoked from network); 2 May 2017 10:37:04 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 May 2017 10:37:04 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 02 May 2017 06:37:04 -0400 (EDT) Received: (qmail 6270 invoked from network); 2 May 2017 10:37:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 May 2017 10:37:04 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 95795EC7D48; Tue, 2 May 2017 03:37:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots] From: Mark Millard In-Reply-To: <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> Date: Tue, 2 May 2017 03:37:03 -0700 Cc: "O. Hartmann" , Tom Vijlbrief Content-Transfer-Encoding: quoted-printable Message-Id: References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> To: freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 10:37:07 -0000 On 2017-May-2, at 2:53 AM, Mark Millard wrote: > On 2017-Apr-30, at 10:15 AM, Mark Millard wrote: >=20 >> On 2017-Apr-30, at 9:40 AM, Andrew Turner = wrote: >>=20 >>>> On 30 Apr 2017, at 12:02, Mark Millard = wrote: >>>> . . . >>>=20 >>> No, the device tree blob comes from UEFI. It seems the current UEFI = only provides the ACPI tables, and not a DTB. >>=20 >> So you are expecting that the older QEMU_EFI.fd I had >> used before provided some sort of fairly generic dtb >> (relative to qemu, fairly independent of the host >> that was running qemu). Interesting. Thanks again. >> . . . >> qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -M virt \ >> -bios QEMU_EFI.fd -nographic \ >> -drive = format=3Draw,if=3Dnone,file=3DFreeBSD-12.0-CURRENT-arm64-aarch64-20170420-= r317181.raw,id=3Dhd0 \ >> -device virtio-blk-device,drive=3Dhd0 \ >> -device virtio-net-device,netdev=3Dnet0 \ >> -netdev user,id=3Dnet0 \ >> -smp cpus=3D4 >>=20 >> based on: >>=20 >> = http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upst= ream/1917/QEMU-AARCH64/RELEASE_CLANG35/QEMU_EFI.fd >=20 > Using the following instead lead to booting > all the way and being able to login: >=20 > = https://releases.linaro.org/components/kernel/uefi-linaro/16.02/release/qe= mu64/QEMU_EFI.fd >=20 > So you were definitely correct. >=20 >> but this time based on my build of head -r317015 . >=20 > This combination seemed more stable than the one > from back in 2016-Sept. >=20 > I strongly expect that the official snapshot would > boot based on this alternate QEMU_EFI.fd as well, > but I've not tried that combination. >=20 > The boot still gets: >=20 > usb_needs_explore_all: no devclass >=20 > during the boot but it does not hang after > that message. >=20 > I have not gotten networking going in > FreeBSD in the quick try that I made. >=20 > So I still do not have a /usr/src in place > to try with a buildworld buildkernel . >=20 > Here is a boot log: >=20 >=20 >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi >=20 > Initializing modules: ZFS UFS > Probing 6 block devices.......*. done > ZFS found no pools > UFS found 1 partition > Consoles: EFI console =20 > Command line arguments: loader.efi > Image base: 0x79c13000 > EFI version: 2.60 > EFI Firmware: EDK II (rev 1.00) >=20 > FreeBSD/arm64 EFI loader, Revision 1.1 > EFI boot environment > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=3D0x7ba068 data=3D0x9e6f8+0x39c3fe = syms=3D[0x8+0x103b60+0x8+0xf8a79] > /boot/entropy size=3D0x1000 >=20 > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... =20 > Using DTB provided by EFI at 0x7ffdd000. > 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 r317015M arm64 > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) > VT: init without driver. > Starting CPU 1 (1) > Starting CPU 2 (2) > Starting CPU 3 (3) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random: unblocking device. > random: entropy device external interface > kbd0 at kbdmux0 > ofwbus0: > simplebus0: on ofwbus0 > clk_fixed0: on ofwbus0 > psci0: on ofwbus0 > gic0: mem = 0x8000000-0x800ffff,0x8010000-0x801ffff on ofwbus0 > gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 288 > gicv2m0: mem = 0x8020000-0x8020fff on gic0 > generic_timer0: irq 34,35,36,37 on ofwbus0 > Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality = 1000 > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > virtio_mmio0: mem 0xa000000-0xa0001ff irq 0 on = ofwbus0 > virtio_mmio1: mem 0xa000200-0xa0003ff irq 1 on = ofwbus0 > virtio_mmio2: mem 0xa000400-0xa0005ff irq 2 on = ofwbus0 > virtio_mmio3: mem 0xa000600-0xa0007ff irq 3 on = ofwbus0 > virtio_mmio4: mem 0xa000800-0xa0009ff irq 4 on = ofwbus0 > virtio_mmio5: mem 0xa000a00-0xa000bff irq 5 on = ofwbus0 > virtio_mmio6: mem 0xa000c00-0xa000dff irq 6 on = ofwbus0 > virtio_mmio7: mem 0xa000e00-0xa000fff irq 7 on = ofwbus0 > virtio_mmio8: mem 0xa001000-0xa0011ff irq 8 on = ofwbus0 > virtio_mmio9: mem 0xa001200-0xa0013ff irq 9 on = ofwbus0 > virtio_mmio10: mem 0xa001400-0xa0015ff irq 10 on = ofwbus0 > virtio_mmio11: mem 0xa001600-0xa0017ff irq 11 on = ofwbus0 > virtio_mmio12: mem 0xa001800-0xa0019ff irq 12 on = ofwbus0 > virtio_mmio13: mem 0xa001a00-0xa001bff irq 13 on = ofwbus0 > virtio_mmio14: mem 0xa001c00-0xa001dff irq 14 on = ofwbus0 > virtio_mmio15: mem 0xa001e00-0xa001fff irq 15 on = ofwbus0 > virtio_mmio16: mem 0xa002000-0xa0021ff irq 16 on = ofwbus0 > virtio_mmio17: mem 0xa002200-0xa0023ff irq 17 on = ofwbus0 > virtio_mmio18: mem 0xa002400-0xa0025ff irq 18 on = ofwbus0 > virtio_mmio19: mem 0xa002600-0xa0027ff irq 19 on = ofwbus0 > virtio_mmio20: mem 0xa002800-0xa0029ff irq 20 on = ofwbus0 > virtio_mmio21: mem 0xa002a00-0xa002bff irq 21 on = ofwbus0 > virtio_mmio22: mem 0xa002c00-0xa002dff irq 22 on = ofwbus0 > virtio_mmio23: mem 0xa002e00-0xa002fff irq 23 on = ofwbus0 > virtio_mmio24: mem 0xa003000-0xa0031ff irq 24 on = ofwbus0 > virtio_mmio25: mem 0xa003200-0xa0033ff irq 25 on = ofwbus0 > virtio_mmio26: mem 0xa003400-0xa0035ff irq 26 on = ofwbus0 > virtio_mmio27: mem 0xa003600-0xa0037ff irq 27 on = ofwbus0 > virtio_mmio28: mem 0xa003800-0xa0039ff irq 28 on = ofwbus0 > virtio_mmio29: mem 0xa003a00-0xa003bff irq 29 on = ofwbus0 > virtio_mmio30: mem 0xa003c00-0xa003dff irq 30 on = ofwbus0 > vtnet0: on virtio_mmio30 > vtnet0: Ethernet address: 52:54:00:12:34:56 > virtio_mmio31: mem 0xa003e00-0xa003fff irq 31 on = ofwbus0 > vtblk0: on virtio_mmio31 > vtblk0: 32768MB (67110465 512 byte sectors) > pcib0: mem 0x3f000000-0x3fffffff on = ofwbus0 > pci0: on pcib0 > uart0: mem 0x9000000-0x9000fff irq 33 on = ofwbus0 > uart0: console (9600,n,8,1) > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpu1: on cpulist0 > cpu2: on cpulist0 > cpu3: on cpulist0 > cryptosoft0: > Timecounters tick every 10.000 msec > usb_needs_explore_all: no devclass > Release APs > CPU 0: ARM Cortex-A53 r0p4 affinity: 0 > Instruction Set Attributes 0 =3D > Instruction Set Attributes 1 =3D <0> > Processor Features 0 =3D > Processor Features 1 =3D <0> > Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> > Memory Model Features 1 =3D <> > Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> > Debug Features 1 =3D <0> > Auxiliary Features 0 =3D <0> > Auxiliary Features 1 =3D <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 > Trying to mount root from ufs:/dev/ufs/rootfs [rw]... > warning: no time-of-day clock registered, system time will not be set = accurately > Setting hostuuid: 5f6ed2d1-2dcc-11e7-b81e-f171534e5634. > Setting hostid: 0x9f2fff5d. > Starting file system checks: > /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/ufs/rootfs: clean, 6154717 free (4485 frags, 768779 blocks, 0.1% = fragmentation) > Mounting local filesystems:. > ELF ldconfig path: /lib /usr/lib /usr/lib/compat > Setting hostname: ODC2FBSD. > Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATT= ACH,CACHED > Feeding entropy: . > Starting Network: lo0 vtnet0. > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128=20 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 > inet 127.0.0.1 netmask 0xff000000=20 > groups: lo=20 > nd6 options=3D21 > vtnet0: flags=3D8802 metric 0 mtu 1500 > options=3D80028 > ether 52:54:00:12:34:56 > media: Ethernet 10Gbase-T > status: active > nd6 options=3D29 > Starting devd. > Starting Network: vtnet0. > vtnet0: flags=3D8802 metric 0 mtu 1500 > options=3D80028 > ether 52:54:00:12:34:56 > media: Ethernet 10Gbase-T > status: active > nd6 options=3D29 > add host 127.0.0.1: gateway lo0 fib 0: route already in table > add host ::1: gateway lo0 fib 0: route already in table > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > Creating and/or trimming log files. > Starting syslogd. > No core dumps found. > Clearing /tmp (X related). > Updating motd:. > Mounting late filesystems:. > Starting sendmail_submit. > Starting sendmail_msp_queue. > Starting cron. > Starting background file system checks in 60 seconds. >=20 > Sun Apr 30 18:41:18 UTC 2017 >=20 > FreeBSD/arm64 (ODC2FBSD) (ttyu0) >=20 > login:=20 FYI: I do sometimes get things like: System shutdown time has arrived Apr 30 19:43:15 ODC2FBSD shutdown: power-down by root:=20 Sleeping thread (tid 100093, pid 708) owns a non-sleepable lock KDB: stack backtrace of thread 100093: sched_switch() at mi_switch+0x100 pc =3D 0xffff000000347d44 lr =3D 0xffff000000327358 sp =3D 0xffff000040237e00 fp =3D 0xffff000040237e20 mi_switch() at sleepq_wait+0x3c pc =3D 0xffff000000327358 lr =3D 0xffff00000036c174 sp =3D 0xffff000040237e30 fp =3D 0xffff000040237e50 sleepq_wait() at _sleep+0x29c pc =3D 0xffff00000036c174 lr =3D 0xffff000000326c7c sp =3D 0xffff000040237e60 fp =3D 0xffff000040237ee0 _sleep() at vm_page_sleep_if_busy+0xb0 pc =3D 0xffff000000326c7c lr =3D 0xffff0000005cfcf4 sp =3D 0xffff000040237ef0 fp =3D 0xffff000040237f10 vm_page_sleep_if_busy() at vm_fault_hold+0xcc8 pc =3D 0xffff0000005cfcf4 lr =3D 0xffff0000005ba17c sp =3D 0xffff000040237f20 fp =3D 0xffff000040238070 vm_fault_hold() at vm_fault+0x70 pc =3D 0xffff0000005ba17c lr =3D 0xffff0000005b9464 sp =3D 0xffff000040238080 fp =3D 0xffff0000402380b0 vm_fault() at data_abort+0xe0 pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 sp =3D 0xffff0000402380c0 fp =3D 0xffff000040238170 data_abort() at handle_el1h_sync+0x70 pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 sp =3D 0xffff000040238180 fp =3D 0xffff000040238290 handle_el1h_sync() at pmap_enter+0x678 pc =3D 0xffff000000607870 lr =3D 0xffff000000615684 sp =3D 0xffff0000402382a0 fp =3D 0xffff0000402383b0 pmap_enter() at vm_fault_hold+0x17c0 pc =3D 0xffff000000615684 lr =3D 0xffff0000005bac74 sp =3D 0xffff0000402383c0 fp =3D 0xffff000040238510 vm_fault_hold() at vm_fault+0x70 pc =3D 0xffff0000005bac74 lr =3D 0xffff0000005b9464 sp =3D 0xffff000040238520 fp =3D 0xffff000040238550 vm_fault() at data_abort+0xe0 pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 sp =3D 0xffff000040238560 fp =3D 0xffff000040238610 data_abort() at handle_el1h_sync+0x70 pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 sp =3D 0xffff000040238620 fp =3D 0xffff000040238730 handle_el1h_sync() at pmap_remove_pages+0x2a8 pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 sp =3D 0xffff000040238740 fp =3D 0xffff000040238870 pmap_remove_pages() at vmspace_exit+0xb0 pc =3D 0xffff0000006175d4 lr =3D 0xffff0000005c020c sp =3D 0xffff000040238880 fp =3D 0xffff0000402388b0 vmspace_exit() at exit1+0x604 pc =3D 0xffff0000005c020c lr =3D 0xffff0000002db5e0 sp =3D 0xffff0000402388c0 fp =3D 0xffff000040238920 exit1() at sys_sys_exit+0x10 pc =3D 0xffff0000002db5e0 lr =3D 0xffff0000002dafd8 sp =3D 0xffff000040238930 fp =3D 0xffff000040238930 sys_sys_exit() at do_el0_sync+0xa48 pc =3D 0xffff0000002dafd8 lr =3D 0xffff00000061b91c sp =3D 0xffff000040238940 fp =3D 0xffff000040238a70 do_el0_sync() at handle_el0_sync+0x6c pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 sp =3D 0xffff000040238a80 fp =3D 0xffff000040238b90 handle_el0_sync() at 0x38cc0 pc =3D 0xffff0000006079e8 lr =3D 0x0000000000038cc0 sp =3D 0xffff000040238ba0 fp =3D 0x0000ffffffffed00 panic: sleeping thread cpuid =3D 2 time =3D 1493581440 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc sp =3D 0xffff000065dfd320 fp =3D 0xffff000065dfd530 db_trace_self_wrapper() at vpanic+0x164 pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 sp =3D 0xffff000065dfd540 fp =3D 0xffff000065dfd5b0 vpanic() at panic+0x4c pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc sp =3D 0xffff000065dfd5c0 fp =3D 0xffff000065dfd640 panic() at propagate_priority+0x2d0 pc =3D 0xffff00000031d2fc lr =3D 0xffff000000374558 sp =3D 0xffff000065dfd650 fp =3D 0xffff000065dfd690 propagate_priority() at turnstile_wait+0x340 pc =3D 0xffff000000374558 lr =3D 0xffff00000037503c sp =3D 0xffff000065dfd6a0 fp =3D 0xffff000065dfd6e0 turnstile_wait() at __rw_wlock_hard+0x208 pc =3D 0xffff00000037503c lr =3D 0xffff000000319138 sp =3D 0xffff000065dfd6f0 fp =3D 0xffff000065dfd770 __rw_wlock_hard() at pmap_enter+0xe98 pc =3D 0xffff000000319138 lr =3D 0xffff000000615ea4 sp =3D 0xffff000065dfd780 fp =3D 0xffff000065dfd810 pmap_enter() at vm_fault_hold+0x28c pc =3D 0xffff000000615ea4 lr =3D 0xffff0000005b9740 sp =3D 0xffff000065dfd820 fp =3D 0xffff000065dfd970 vm_fault_hold() at vm_fault+0x70 pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 sp =3D 0xffff000065dfd980 fp =3D 0xffff000065dfd9b0 vm_fault() at data_abort+0xe0 pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 sp =3D 0xffff000065dfd9c0 fp =3D 0xffff000065dfda70 data_abort() at handle_el0_sync+0x6c pc =3D 0xffff00000061ad94 lr =3D 0xffff0000006079e8 sp =3D 0xffff000065dfda80 fp =3D 0xffff000065dfdb90 handle_el0_sync() at 0x40040070 pc =3D 0xffff0000006079e8 lr =3D 0x0000000040040070 sp =3D 0xffff000065dfdba0 fp =3D 0x0000ffffffffeb00 KDB: enter: panic [ thread pid 709 tid 100086 ] Stopped at kdb_enter+0x44: undefined d4200000 db> =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue May 2 10:43: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 6036BD581DA for ; Tue, 2 May 2017 10:43:53 +0000 (UTC) (envelope-from aggaz@paranoici.org) Received: from perdizione.investici.org (perdizione.investici.org [IPv6:2001:41d0:2:33d0::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.autistici.org", Issuer "Autistici/Inventati Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 26C3FFE7 for ; Tue, 2 May 2017 10:43:52 +0000 (UTC) (envelope-from aggaz@paranoici.org) Received: from [94.23.50.208] (perdizione [94.23.50.208]) (Authenticated sender: aggaz@paranoici.org) by localhost (Postfix) with ESMTPSA id 4F88E120154; Tue, 2 May 2017 10:43:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paranoici.org; s=stigmate; t=1493721822; bh=INZEmpb4yd7GDwFpS36TNRmZzPyOVO+IOiFhlrlzabI=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=VNGAgrrcE0k4BaKWp4YP1jA1yDs4VRNLo1BpZ0gQ/Ayi96B61SdcaSzCVpdyVhqAn vJjmBBMdGHPkjjDntKhBD8v/ILlzK7NiAP3De7cJMq+Fhew3HDv7VvdVzw3wYUR2UB KEjTUj8llKnK7UqDz0VWQuW7+nmi4PhSLWClBwqU= Subject: Re: FreeBSD 12-CURRENT on OrangePi One To: Emmanuel Vadot References: <9e04f3cf-ddce-1b53-b9d6-2fe05ad1cc25@paranoici.org> <20170502105507.4c51a7323bd01903e402f551@bidouilliste.com> Cc: freebsd-arm@freebsd.org From: aggaz Message-ID: <64893df0-f9f7-d24b-8644-bc84824fc657@paranoici.org> Date: Tue, 2 May 2017 12:43:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170502105507.4c51a7323bd01903e402f551@bidouilliste.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 10:43:53 -0000 Dear Emmanuel, In the last days I found and tried the dts file you are referring to (the one in sys/gnu/.../...). I compiled it using crochet, and I can confirm that it boots, it supports USB but not Ethernet. It also seems to me that it is less stable than the other two I tried (the one for OrangePi Plus 2E and the one from NanoPi Neo). Maybe it is not related to the dts, but I saw several random glitches after boot that make me think that this Linux-imported dts is not 100% compatible. I hope you find the dts with both ethernet and usb. A question: would it be possible to integrate the ethernet portion of the dts for NanoPi to the dts for OrangePiPlus 2E? I am trying to do so in the last days, but I do not really understand how to write a DTS file... I am also looking for documentation, without so much luck, if you have some link/book/manual you feel like sharing, please do. Regards Aggaz Il 02/05/2017 10:55, Emmanuel Vadot ha scritto: > On Sun, 30 Apr 2017 12:27:04 +0200 > aggaz wrote: > >> Dear list, >> >> as I previously wrote, I am trying to use FreeBSD 12-CURRENT on OrangePi >> One by using crochet. >> >> One problem is that there are no dtb files available specific for this >> board. > > There is one in sys/gnu/dts, I was sure that I added it to the list of > DTS we compile but ... > >> Now I compared two dtb files for the same SoC (H3): one for NanoPi Neo >> (/boot/dtb/nanopi-neo.dtb) and one for OrangePi Plus 2E >> (/boot/dtb/orangepi-plus-2e.dtb). >> >> Both makes the board boot fine without issues, but: >> >> 1) dtb file for NanoPi Neo makes the network interface available and >> working, but not the USB port. >> >> 2) dtb file for OrangePi Plus 2E makes the USB port available and >> working, but not the network interface. > > Please note that ethernet DTS bindings aren't standardized yet and > since I don't want us to heavily patches the DTS or derive to much from > the Linux one if I add the OrangePi One DTS to the build it will > probably be without ethernet support. > > Anyway, I have one somewhere with USB and ethernet support, I'll look > to commit/share that soon. > >> >> At this point I don't really know what I can do to make both interfaces >> working at the same time, and I am writing this to ask you some suggestions. >> >> Any idea would be greatly appreciated. >> >> Regards >> Aggaz >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > From owner-freebsd-arm@freebsd.org Tue May 2 10:48:46 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44885D5839E for ; Tue, 2 May 2017 10:48:46 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d: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 0873A1529 for ; Tue, 2 May 2017 10:48:45 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x22a.google.com with SMTP id q1so38549756qkd.2 for ; Tue, 02 May 2017 03:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=qiMLkxkrW6O+oqNEV7F6uAJ36FUKvSqP0013cT+zUHQ=; b=XWScE15llUdF/+lezkspZuWp+PJo+dlAbLbGchfYKCFqA/AkzViMR98NU9HI0rNhwP FQHbztdPr5QibDrGh3nd+Mq75ug4i/d8luu9J4nONCfFqwEkkQaBzlN1/JiJcB8Egwkv aYx3a1l8pIYdMMnuMm1TmYlpFuIUVNeVUa4xg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qiMLkxkrW6O+oqNEV7F6uAJ36FUKvSqP0013cT+zUHQ=; b=sn83g5CohtnlLdJfvhkQ2zQgJ++Eq+ti21kKXyqWMzxdLqxtVExpXPg95xrcW4z5SQ sT3oUPJhwtwJy7N2CgCrUjY+MMfZqiKp/PrHwxJ2QIwlKKqc9uPIQkprf+wl0H2DaGmR CDijMyLOOg28Lg1ck6aADDiXSv4WVweoghcqt/nFAfBvgjuktQlvvjzNs3F+nq7akKcc fHZhL6NdwJJ5KZo2xArklFfgHfHyx52is+uarsCD3qaRFk4qiB2CiIqtPplUmJGVi6pv Ks0ZxF922RrM6olFjxDd4YDiVbCX1yw5eYPoTbOfSUH6X3ddP8SlayXqismipKIta5eP iQBw== X-Gm-Message-State: AN3rC/62H4Bhf96jjDjxnwJYnWiMYuVYNjuFaWkKhliK76Nq9VawEV/f mfTSD4eLVEQNa/xB X-Received: by 10.55.128.1 with SMTP id b1mr24726467qkd.226.1493722124582; Tue, 02 May 2017 03:48:44 -0700 (PDT) Received: from ?IPv6:2804:54:19ef:cc00:4a9:b9da:e5eb:169d? ([2804:54:19ef:cc00:4a9:b9da:e5eb:169d]) by smtp.googlemail.com with ESMTPSA id q40sm14791408qtq.21.2017.05.02.03.48.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 03:48:43 -0700 (PDT) Subject: Re: lock when building llvm37 on RPI3 To: freebsd-arm@freebsd.org References: <0b4b8a6f-f008-4892-a7c1-73fab2a79030@bsd.com.br> <4085737d-af52-3f21-c593-3be249b59d46@zyxst.net> From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <9d7569cd-e2fd-0e6b-225f-bf800eae3e25@bsd.com.br> Date: Tue, 2 May 2017 07:48:33 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4085737d-af52-3f21-c593-3be249b59d46@zyxst.net> Content-Type: text/plain; charset=utf-8; format=flowed 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, 02 May 2017 10:48:46 -0000 Em 02/05/2017 07:16, tech-lists escreveu: > On 02/05/2017 02:22, Otacílio wrote: >> To those who are using ARM64, have you compiled large software like >> llvm? I'm trying to compile llvm37 but, at first try, the system spent >> more than an hour on [42/3588] when compiling llvm37 as a dependency of >> webcamd. Then, I reset and it passed quickly from 42 and is now on >> [148/3588]. I also faced two crashes when I was trying to do this for >> ssh, but unfortunately I had no monitor connected to RPI3. I am using >> head revision 317063. > Hi, > > 1. did you install ccache first? It makes a really big difference. And > then tell /etc/make.conf to use it? > 2. have you mounted /usr/obj onto separate hardware, like a usb stick? > 3. is /tmp also offloaded similarly? > Hello 1. No, I not installed ccache previously. Thank you by your hint. 2. Yes. I'm using a external USB hard disk (Seagate, 500 GB auto powered). /usr/obj /usr/ports and /usr/src is mounted there. 3. No. I will do it also. Unhappily I was using a NODEBUG kernel and no hint about the deadlock was printed. Maybe the deadlock can be caused by the micro SD HC card used but I can not affirm. I give another try and this time I got a kernel panic at reclaim_pv_chunk http://imgur.com/XLiziq1 From owner-freebsd-arm@freebsd.org Tue May 2 11:23:16 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F6F0D58FF1 for ; Tue, 2 May 2017 11:23:16 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BAF87B5 for ; Tue, 2 May 2017 11:23:14 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 74267f3f; Tue, 2 May 2017 13:23:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=KX9XqwhcN7IC2HDtr8wdbMDaHiM=; b=DTIuY6D/lqvHl2KJhXrRzvbOzlCm +UWign743a5N2OkBlPk0zaqn0z5AH8OBDzGNGe8CJEdiyFUjd95G3QH1PO7Yyqrb ZLWWKSNnAABk7Rte9FzVtikUus16U/tbH3bva6DUwZ+1BSzJdx6LtiFNSVv4AQ8A Zf4UJ7R/WCfXhQc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=OxVEyE4AOMa8MJdBJnuD2h75VouMOyKsG83QEgN1Bi55FiwPxoS1Mrwi 3kFYNIXaAL8qSg+cQz7t7cp/aLNIrrmCBe+2wSWAjkBcLm80euYzrsrmkBV5k8fn zPAWcVOnjFodRZJzdGDJvCaZjQz9pEsKRdJVPdaATTBLRoX+l0A= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 2df3ce06 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 2 May 2017 13:23:12 +0200 (CEST) Date: Tue, 2 May 2017 13:23:11 +0200 From: Emmanuel Vadot To: aggaz Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD 12-CURRENT on OrangePi One Message-Id: <20170502132311.26aa210165fc10f5435def80@bidouilliste.com> In-Reply-To: <64893df0-f9f7-d24b-8644-bc84824fc657@paranoici.org> References: <9e04f3cf-ddce-1b53-b9d6-2fe05ad1cc25@paranoici.org> <20170502105507.4c51a7323bd01903e402f551@bidouilliste.com> <64893df0-f9f7-d24b-8644-bc84824fc657@paranoici.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 11:23:16 -0000 On Tue, 2 May 2017 12:43:41 +0200 aggaz wrote: > Dear Emmanuel, > > In the last days I found and tried the dts file you are referring to > (the one in sys/gnu/.../...). > I compiled it using crochet, and I can confirm that it boots, it > supports USB but not Ethernet. > > It also seems to me that it is less stable than the other two I tried > (the one for OrangePi Plus 2E and the one from NanoPi Neo). Less stable in what way ? > Maybe it is not related to the dts, but I saw several random glitches > after boot that make me think that this Linux-imported dts is not 100% > compatible. Random glitches of what exactly ? > I hope you find the dts with both ethernet and usb. > > A question: would it be possible to integrate the ethernet portion of > the dts for NanoPi to the dts for OrangePiPlus 2E? I don't think I have the Plus 2E so I won't be able to test, I think the only difference would be the regulator for the PHY (or the usage of internal PHY). > I am trying to do so in the last days, but I do not really understand > how to write a DTS file... > > I am also looking for documentation, without so much luck, if you have > some link/book/manual you feel like sharing, please do. There is none afaik, just read the binding docs from the Linux kernel Documentation. > Regards > Aggaz Cheers, > Il 02/05/2017 10:55, Emmanuel Vadot ha scritto: > > On Sun, 30 Apr 2017 12:27:04 +0200 > > aggaz wrote: > > > >> Dear list, > >> > >> as I previously wrote, I am trying to use FreeBSD 12-CURRENT on OrangePi > >> One by using crochet. > >> > >> One problem is that there are no dtb files available specific for this > >> board. > > > > There is one in sys/gnu/dts, I was sure that I added it to the list of > > DTS we compile but ... > > > >> Now I compared two dtb files for the same SoC (H3): one for NanoPi Neo > >> (/boot/dtb/nanopi-neo.dtb) and one for OrangePi Plus 2E > >> (/boot/dtb/orangepi-plus-2e.dtb). > >> > >> Both makes the board boot fine without issues, but: > >> > >> 1) dtb file for NanoPi Neo makes the network interface available and > >> working, but not the USB port. > >> > >> 2) dtb file for OrangePi Plus 2E makes the USB port available and > >> working, but not the network interface. > > > > Please note that ethernet DTS bindings aren't standardized yet and > > since I don't want us to heavily patches the DTS or derive to much from > > the Linux one if I add the OrangePi One DTS to the build it will > > probably be without ethernet support. > > > > Anyway, I have one somewhere with USB and ethernet support, I'll look > > to commit/share that soon. > > > >> > >> At this point I don't really know what I can do to make both interfaces > >> working at the same time, and I am writing this to ask you some suggestions. > >> > >> Any idea would be greatly appreciated. > >> > >> Regards > >> Aggaz > >> _______________________________________________ > >> 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" > > > > -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue May 2 12:24:27 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47F23D5AEBC for ; Tue, 2 May 2017 12:24:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-51.reflexion.net [208.70.210.51]) (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 06B8912DF for ; Tue, 2 May 2017 12:24:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26253 invoked from network); 2 May 2017 12:24:25 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 May 2017 12:24:25 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 02 May 2017 08:24:25 -0400 (EDT) Received: (qmail 15998 invoked from network); 2 May 2017 12:24:24 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 May 2017 12:24:24 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1DAEEEC7D48; Tue, 2 May 2017 05:24:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots] From: Mark Millard In-Reply-To: Date: Tue, 2 May 2017 05:24:23 -0700 Cc: "O. Hartmann" , Tom Vijlbrief Content-Transfer-Encoding: quoted-printable Message-Id: References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> To: freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 12:24:27 -0000 On 2017-May-2, at 3:37 AM, Mark Millard wrote: > On 2017-May-2, at 2:53 AM, Mark Millard wrote: >=20 >> On 2017-Apr-30, at 10:15 AM, Mark Millard = wrote: >>=20 >>> On 2017-Apr-30, at 9:40 AM, Andrew Turner = wrote: >>>=20 >>>>> On 30 Apr 2017, at 12:02, Mark Millard = wrote: >>>>> . . . >>>>=20 >>>> No, the device tree blob comes from UEFI. It seems the current UEFI = only provides the ACPI tables, and not a DTB. >>>=20 >>> So you are expecting that the older QEMU_EFI.fd I had >>> used before provided some sort of fairly generic dtb >>> (relative to qemu, fairly independent of the host >>> that was running qemu). Interesting. Thanks again. >>> . . . >>> qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -M virt \ >>> -bios QEMU_EFI.fd -nographic \ >>> -drive = format=3Draw,if=3Dnone,file=3DFreeBSD-12.0-CURRENT-arm64-aarch64-20170420-= r317181.raw,id=3Dhd0 \ >>> -device virtio-blk-device,drive=3Dhd0 \ >>> -device virtio-net-device,netdev=3Dnet0 \ >>> -netdev user,id=3Dnet0 \ >>> -smp cpus=3D4 >>>=20 >>> based on: >>>=20 >>> = http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upst= ream/1917/QEMU-AARCH64/RELEASE_CLANG35/QEMU_EFI.fd >>=20 >> Using the following instead lead to booting >> all the way and being able to login: >>=20 >> = https://releases.linaro.org/components/kernel/uefi-linaro/16.02/release/qe= mu64/QEMU_EFI.fd >>=20 >> So you were definitely correct. >>=20 >>> but this time based on my build of head -r317015 . >>=20 >> This combination seemed more stable than the one >> from back in 2016-Sept. >>=20 >> I strongly expect that the official snapshot would >> boot based on this alternate QEMU_EFI.fd as well, >> but I've not tried that combination. >>=20 >> The boot still gets: >>=20 >> usb_needs_explore_all: no devclass >>=20 >> during the boot but it does not hang after >> that message. >>=20 >> I have not gotten networking going in >> FreeBSD in the quick try that I made. >>=20 >> So I still do not have a /usr/src in place >> to try with a buildworld buildkernel . >>=20 >> Here is a boot log: >>=20 >>=20 >>>> FreeBSD EFI boot block >> Loader path: /boot/loader.efi >>=20 >> Initializing modules: ZFS UFS >> Probing 6 block devices.......*. done >> ZFS found no pools >> UFS found 1 partition >> Consoles: EFI console =20 >> Command line arguments: loader.efi >> Image base: 0x79c13000 >> EFI version: 2.60 >> EFI Firmware: EDK II (rev 1.00) >>=20 >> FreeBSD/arm64 EFI loader, Revision 1.1 >> EFI boot environment >> Loading /boot/defaults/loader.conf >> /boot/kernel/kernel text=3D0x7ba068 data=3D0x9e6f8+0x39c3fe = syms=3D[0x8+0x103b60+0x8+0xf8a79] >> /boot/entropy size=3D0x1000 >>=20 >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... =20 >> Using DTB provided by EFI at 0x7ffdd000. >> 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 r317015M arm64 >> FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) >> VT: init without driver. >> Starting CPU 1 (1) >> Starting CPU 2 (2) >> Starting CPU 3 (3) >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> random: unblocking device. >> random: entropy device external interface >> kbd0 at kbdmux0 >> ofwbus0: >> simplebus0: on ofwbus0 >> clk_fixed0: on ofwbus0 >> psci0: on ofwbus0 >> gic0: mem = 0x8000000-0x800ffff,0x8010000-0x801ffff on ofwbus0 >> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 288 >> gicv2m0: mem = 0x8020000-0x8020fff on gic0 >> generic_timer0: irq 34,35,36,37 on ofwbus0 >> Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality = 1000 >> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality = 1000 >> virtio_mmio0: mem 0xa000000-0xa0001ff irq 0 on = ofwbus0 >> virtio_mmio1: mem 0xa000200-0xa0003ff irq 1 on = ofwbus0 >> virtio_mmio2: mem 0xa000400-0xa0005ff irq 2 on = ofwbus0 >> virtio_mmio3: mem 0xa000600-0xa0007ff irq 3 on = ofwbus0 >> virtio_mmio4: mem 0xa000800-0xa0009ff irq 4 on = ofwbus0 >> virtio_mmio5: mem 0xa000a00-0xa000bff irq 5 on = ofwbus0 >> virtio_mmio6: mem 0xa000c00-0xa000dff irq 6 on = ofwbus0 >> virtio_mmio7: mem 0xa000e00-0xa000fff irq 7 on = ofwbus0 >> virtio_mmio8: mem 0xa001000-0xa0011ff irq 8 on = ofwbus0 >> virtio_mmio9: mem 0xa001200-0xa0013ff irq 9 on = ofwbus0 >> virtio_mmio10: mem 0xa001400-0xa0015ff irq 10 = on ofwbus0 >> virtio_mmio11: mem 0xa001600-0xa0017ff irq 11 = on ofwbus0 >> virtio_mmio12: mem 0xa001800-0xa0019ff irq 12 = on ofwbus0 >> virtio_mmio13: mem 0xa001a00-0xa001bff irq 13 = on ofwbus0 >> virtio_mmio14: mem 0xa001c00-0xa001dff irq 14 = on ofwbus0 >> virtio_mmio15: mem 0xa001e00-0xa001fff irq 15 = on ofwbus0 >> virtio_mmio16: mem 0xa002000-0xa0021ff irq 16 = on ofwbus0 >> virtio_mmio17: mem 0xa002200-0xa0023ff irq 17 = on ofwbus0 >> virtio_mmio18: mem 0xa002400-0xa0025ff irq 18 = on ofwbus0 >> virtio_mmio19: mem 0xa002600-0xa0027ff irq 19 = on ofwbus0 >> virtio_mmio20: mem 0xa002800-0xa0029ff irq 20 = on ofwbus0 >> virtio_mmio21: mem 0xa002a00-0xa002bff irq 21 = on ofwbus0 >> virtio_mmio22: mem 0xa002c00-0xa002dff irq 22 = on ofwbus0 >> virtio_mmio23: mem 0xa002e00-0xa002fff irq 23 = on ofwbus0 >> virtio_mmio24: mem 0xa003000-0xa0031ff irq 24 = on ofwbus0 >> virtio_mmio25: mem 0xa003200-0xa0033ff irq 25 = on ofwbus0 >> virtio_mmio26: mem 0xa003400-0xa0035ff irq 26 = on ofwbus0 >> virtio_mmio27: mem 0xa003600-0xa0037ff irq 27 = on ofwbus0 >> virtio_mmio28: mem 0xa003800-0xa0039ff irq 28 = on ofwbus0 >> virtio_mmio29: mem 0xa003a00-0xa003bff irq 29 = on ofwbus0 >> virtio_mmio30: mem 0xa003c00-0xa003dff irq 30 = on ofwbus0 >> vtnet0: on virtio_mmio30 >> vtnet0: Ethernet address: 52:54:00:12:34:56 >> virtio_mmio31: mem 0xa003e00-0xa003fff irq 31 = on ofwbus0 >> vtblk0: on virtio_mmio31 >> vtblk0: 32768MB (67110465 512 byte sectors) >> pcib0: mem 0x3f000000-0x3fffffff on = ofwbus0 >> pci0: on pcib0 >> uart0: mem 0x9000000-0x9000fff irq 33 on = ofwbus0 >> uart0: console (9600,n,8,1) >> cpulist0: on ofwbus0 >> cpu0: on cpulist0 >> cpu1: on cpulist0 >> cpu2: on cpulist0 >> cpu3: on cpulist0 >> cryptosoft0: >> Timecounters tick every 10.000 msec >> usb_needs_explore_all: no devclass >> Release APs >> CPU 0: ARM Cortex-A53 r0p4 affinity: 0 >> Instruction Set Attributes 0 =3D >> Instruction Set Attributes 1 =3D <0> >> Processor Features 0 =3D >> Processor Features 1 =3D <0> >> Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> >> Memory Model Features 1 =3D <> >> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> >> Debug Features 1 =3D <0> >> Auxiliary Features 0 =3D <0> >> Auxiliary Features 1 =3D <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 >> Trying to mount root from ufs:/dev/ufs/rootfs [rw]... >> warning: no time-of-day clock registered, system time will not be set = accurately >> Setting hostuuid: 5f6ed2d1-2dcc-11e7-b81e-f171534e5634. >> Setting hostid: 0x9f2fff5d. >> Starting file system checks: >> /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS >> /dev/ufs/rootfs: clean, 6154717 free (4485 frags, 768779 blocks, 0.1% = fragmentation) >> Mounting local filesystems:. >> ELF ldconfig path: /lib /usr/lib /usr/lib/compat >> Setting hostname: ODC2FBSD. >> Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATT= ACH,CACHED >> Feeding entropy: . >> Starting Network: lo0 vtnet0. >> lo0: flags=3D8049 metric 0 mtu 16384 >> options=3D600003 >> inet6 ::1 prefixlen 128=20 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 >> inet 127.0.0.1 netmask 0xff000000=20 >> groups: lo=20 >> nd6 options=3D21 >> vtnet0: flags=3D8802 metric 0 mtu 1500 >> options=3D80028 >> ether 52:54:00:12:34:56 >> media: Ethernet 10Gbase-T >> status: active >> nd6 options=3D29 >> Starting devd. >> Starting Network: vtnet0. >> vtnet0: flags=3D8802 metric 0 mtu 1500 >> options=3D80028 >> ether 52:54:00:12:34:56 >> media: Ethernet 10Gbase-T >> status: active >> nd6 options=3D29 >> add host 127.0.0.1: gateway lo0 fib 0: route already in table >> add host ::1: gateway lo0 fib 0: route already in table >> add net fe80::: gateway ::1 >> add net ff02::: gateway ::1 >> add net ::ffff:0.0.0.0: gateway ::1 >> add net ::0.0.0.0: gateway ::1 >> Creating and/or trimming log files. >> Starting syslogd. >> No core dumps found. >> Clearing /tmp (X related). >> Updating motd:. >> Mounting late filesystems:. >> Starting sendmail_submit. >> Starting sendmail_msp_queue. >> Starting cron. >> Starting background file system checks in 60 seconds. >>=20 >> Sun Apr 30 18:41:18 UTC 2017 >>=20 >> FreeBSD/arm64 (ODC2FBSD) (ttyu0) >>=20 >> login:=20 >=20 > FYI: >=20 > I do sometimes get things like: >=20 >=20 > System shutdown time has arrived > Apr 30 19:43:15 ODC2FBSD shutdown: power-down by root:=20 > Sleeping thread (tid 100093, pid 708) owns a non-sleepable lock > KDB: stack backtrace of thread 100093: > sched_switch() at mi_switch+0x100 > pc =3D 0xffff000000347d44 lr =3D 0xffff000000327358 > sp =3D 0xffff000040237e00 fp =3D 0xffff000040237e20 >=20 > mi_switch() at sleepq_wait+0x3c > pc =3D 0xffff000000327358 lr =3D 0xffff00000036c174 > sp =3D 0xffff000040237e30 fp =3D 0xffff000040237e50 >=20 > sleepq_wait() at _sleep+0x29c > pc =3D 0xffff00000036c174 lr =3D 0xffff000000326c7c > sp =3D 0xffff000040237e60 fp =3D 0xffff000040237ee0 >=20 > _sleep() at vm_page_sleep_if_busy+0xb0 > pc =3D 0xffff000000326c7c lr =3D 0xffff0000005cfcf4 > sp =3D 0xffff000040237ef0 fp =3D 0xffff000040237f10 >=20 > vm_page_sleep_if_busy() at vm_fault_hold+0xcc8 > pc =3D 0xffff0000005cfcf4 lr =3D 0xffff0000005ba17c > sp =3D 0xffff000040237f20 fp =3D 0xffff000040238070 >=20 > vm_fault_hold() at vm_fault+0x70 > pc =3D 0xffff0000005ba17c lr =3D 0xffff0000005b9464 > sp =3D 0xffff000040238080 fp =3D 0xffff0000402380b0 >=20 > vm_fault() at data_abort+0xe0 > pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 > sp =3D 0xffff0000402380c0 fp =3D 0xffff000040238170 >=20 > data_abort() at handle_el1h_sync+0x70 > pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 > sp =3D 0xffff000040238180 fp =3D 0xffff000040238290 >=20 > handle_el1h_sync() at pmap_enter+0x678 > pc =3D 0xffff000000607870 lr =3D 0xffff000000615684 > sp =3D 0xffff0000402382a0 fp =3D 0xffff0000402383b0 >=20 > pmap_enter() at vm_fault_hold+0x17c0 > pc =3D 0xffff000000615684 lr =3D 0xffff0000005bac74 > sp =3D 0xffff0000402383c0 fp =3D 0xffff000040238510 >=20 > vm_fault_hold() at vm_fault+0x70 > pc =3D 0xffff0000005bac74 lr =3D 0xffff0000005b9464 > sp =3D 0xffff000040238520 fp =3D 0xffff000040238550 >=20 > vm_fault() at data_abort+0xe0 > pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 > sp =3D 0xffff000040238560 fp =3D 0xffff000040238610 >=20 > data_abort() at handle_el1h_sync+0x70 > pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 > sp =3D 0xffff000040238620 fp =3D 0xffff000040238730 >=20 > handle_el1h_sync() at pmap_remove_pages+0x2a8 > pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 > sp =3D 0xffff000040238740 fp =3D 0xffff000040238870 >=20 > pmap_remove_pages() at vmspace_exit+0xb0 > pc =3D 0xffff0000006175d4 lr =3D 0xffff0000005c020c > sp =3D 0xffff000040238880 fp =3D 0xffff0000402388b0 >=20 > vmspace_exit() at exit1+0x604 > pc =3D 0xffff0000005c020c lr =3D 0xffff0000002db5e0 > sp =3D 0xffff0000402388c0 fp =3D 0xffff000040238920 >=20 > exit1() at sys_sys_exit+0x10 > pc =3D 0xffff0000002db5e0 lr =3D 0xffff0000002dafd8 > sp =3D 0xffff000040238930 fp =3D 0xffff000040238930 >=20 > sys_sys_exit() at do_el0_sync+0xa48 > pc =3D 0xffff0000002dafd8 lr =3D 0xffff00000061b91c > sp =3D 0xffff000040238940 fp =3D 0xffff000040238a70 >=20 > do_el0_sync() at handle_el0_sync+0x6c > pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 > sp =3D 0xffff000040238a80 fp =3D 0xffff000040238b90 >=20 > handle_el0_sync() at 0x38cc0 > pc =3D 0xffff0000006079e8 lr =3D 0x0000000000038cc0 > sp =3D 0xffff000040238ba0 fp =3D 0x0000ffffffffed00 >=20 > panic: sleeping thread > cpuid =3D 2 > time =3D 1493581440 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc > sp =3D 0xffff000065dfd320 fp =3D 0xffff000065dfd530 >=20 > db_trace_self_wrapper() at vpanic+0x164 > pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 > sp =3D 0xffff000065dfd540 fp =3D 0xffff000065dfd5b0 >=20 > vpanic() at panic+0x4c > pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc > sp =3D 0xffff000065dfd5c0 fp =3D 0xffff000065dfd640 >=20 > panic() at propagate_priority+0x2d0 > pc =3D 0xffff00000031d2fc lr =3D 0xffff000000374558 > sp =3D 0xffff000065dfd650 fp =3D 0xffff000065dfd690 >=20 > propagate_priority() at turnstile_wait+0x340 > pc =3D 0xffff000000374558 lr =3D 0xffff00000037503c > sp =3D 0xffff000065dfd6a0 fp =3D 0xffff000065dfd6e0 >=20 > turnstile_wait() at __rw_wlock_hard+0x208 > pc =3D 0xffff00000037503c lr =3D 0xffff000000319138 > sp =3D 0xffff000065dfd6f0 fp =3D 0xffff000065dfd770 >=20 > __rw_wlock_hard() at pmap_enter+0xe98 > pc =3D 0xffff000000319138 lr =3D 0xffff000000615ea4 > sp =3D 0xffff000065dfd780 fp =3D 0xffff000065dfd810 >=20 > pmap_enter() at vm_fault_hold+0x28c > pc =3D 0xffff000000615ea4 lr =3D 0xffff0000005b9740 > sp =3D 0xffff000065dfd820 fp =3D 0xffff000065dfd970 >=20 > vm_fault_hold() at vm_fault+0x70 > pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 > sp =3D 0xffff000065dfd980 fp =3D 0xffff000065dfd9b0 >=20 > vm_fault() at data_abort+0xe0 > pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 > sp =3D 0xffff000065dfd9c0 fp =3D 0xffff000065dfda70 >=20 > data_abort() at handle_el0_sync+0x6c > pc =3D 0xffff00000061ad94 lr =3D 0xffff0000006079e8 > sp =3D 0xffff000065dfda80 fp =3D 0xffff000065dfdb90 >=20 > handle_el0_sync() at 0x40040070 > pc =3D 0xffff0000006079e8 lr =3D 0x0000000040040070 > sp =3D 0xffff000065dfdba0 fp =3D 0x0000ffffffffeb00 >=20 > KDB: enter: panic > [ thread pid 709 tid 100086 ] > Stopped at kdb_enter+0x44: undefined d4200000 > db> Another example failure is: Fatal data abort: x0: 400a9000 x1: 1000 x2: 0 x3: 40 x4: 3f x5: fffffd00304e5000 x6: 2b52 x7: c x8: b x9: fffffd000076d5d0 x10: 68 x11: 40000000 x12: 704c5000 x13: 42b42003 x14: 42b42003 x15: 40000000 x16: c x17: ffffffffffffffff x18: ffff000065dd5310 x19: 800000000000000 x20: 1 x21: fffffd0002b43000 x22: 12000004556478b x23: f000000000000000 x24: fffffd0002b41bc8 x25: 40 x26: fffffd0002b42548 x27: 7b x28: 3 x29: ffff000065dd53c0 sp: ffff000065dd5310 lr: ffff0000006175d8 elr: ffff00000060589c spsr: 60000345 far: 400a9000 esr: 96000147 [ thread pid 715 tid 100078 ] Stopped at arm64_dcache_wb_range+0x18: undefined d50b7a20 db> bt Tracing pid 715 tid 100078 td 0xfffffd00007849c0 db_trace_self() at db_stack_trace+0xf0 pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000840e0 sp =3D 0xffff000065dd4cb0 fp =3D 0xffff000065dd4ce0 db_stack_trace() at db_command+0x23c pc =3D 0xffff0000000840e0 lr =3D 0xffff000000083d58 sp =3D 0xffff000065dd4cf0 fp =3D 0xffff000065dd4dd0 db_command() at db_command_loop+0x60 pc =3D 0xffff000000083d58 lr =3D 0xffff000000083b00 sp =3D 0xffff000065dd4de0 fp =3D 0xffff000065dd4e00 db_command_loop() at db_trap+0xf4 pc =3D 0xffff000000083b00 lr =3D 0xffff000000086b34 sp =3D 0xffff000065dd4e10 fp =3D 0xffff000065dd5030 db_trap() at kdb_trap+0x180 pc =3D 0xffff000000086b34 lr =3D 0xffff00000035f650 sp =3D 0xffff000065dd5040 fp =3D 0xffff000065dd50a0 =20 kdb_trap() at data_abort+0x1a0 pc =3D 0xffff00000035f650 lr =3D 0xffff00000061ae54 sp =3D 0xffff000065dd50b0 fp =3D 0xffff000065dd5160 data_abort() at handle_el1h_sync+0x70 pc =3D 0xffff00000061ae54 lr =3D 0xffff000000607870 sp =3D 0xffff000065dd5170 fp =3D 0xffff000065dd5280 handle_el1h_sync() at pmap_remove_pages+0x2a8 pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 sp =3D 0xffff000065dd5290 fp =3D 0xffff000065dd53c0 pmap_remove_pages() at exec_new_vmspace+0x1a4 pc =3D 0xffff0000006175d4 lr =3D 0xffff0000002d9da0 sp =3D 0xffff000065dd53d0 fp =3D 0xffff000065dd5430 exec_new_vmspace() at exec_elf64_imgact+0xa70 pc =3D 0xffff0000002d9da0 lr =3D 0xffff0000002b7c14 sp =3D 0xffff000065dd5440 fp =3D 0xffff000065dd5550 =20 exec_elf64_imgact() at kern_execve+0x664 pc =3D 0xffff0000002b7c14 lr =3D 0xffff0000002d8730 sp =3D 0xffff000065dd5560 fp =3D 0xffff000065dd58b0 kern_execve() at sys_execve+0x54 pc =3D 0xffff0000002d8730 lr =3D 0xffff0000002d7d90 sp =3D 0xffff000065dd58c0 fp =3D 0xffff000065dd5930 sys_execve() at do_el0_sync+0xa48 pc =3D 0xffff0000002d7d90 lr =3D 0xffff00000061b91c sp =3D 0xffff000065dd5940 fp =3D 0xffff000065dd5a70 do_el0_sync() at handle_el0_sync+0x6c pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 sp =3D 0xffff000065dd5a80 fp =3D 0xffff000065dd5b90 handle_el0_sync() at 0x24a90 pc =3D 0xffff0000006079e8 lr =3D 0x0000000000024a90 sp =3D 0xffff000065dd5ba0 fp =3D 0x0000ffffffffe7d0 =20 db>=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue May 2 13:10:51 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2D3BD5ACF9 for ; Tue, 2 May 2017 13:10:51 +0000 (UTC) (envelope-from aggaz@paranoici.org) Received: from latitanza.investici.org (latitanza.investici.org [IPv6:2001:888:2000:56::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.autistici.org", Issuer "Autistici/Inventati Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 684F11FD for ; Tue, 2 May 2017 13:10:50 +0000 (UTC) (envelope-from aggaz@paranoici.org) Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: aggaz@paranoici.org) by localhost (Postfix) with ESMTPSA id C3DB6120D8D; Tue, 2 May 2017 13:10:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paranoici.org; s=stigmate; t=1493730648; bh=cNU1IdL7LpKAPGkPieTUzMxVN2b5R0hgPqDvSRWZFWE=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=jZCsHCBzHFCLqx4Fvz1g0bDyT9XErUmsihH5sGsjnclDANP1QGd3SrFkMgWDHgpMC gyR02JgMv3Xd4qdzHqRcA+irTa5puE7R+ZF3AYDI2yuw9CEyR+Vig1PJy24nWVnoKj iClfQQiXMwvkYiWbS5+ANVmjCZJOzaMn0lMbX2hE= Subject: Re: FreeBSD 12-CURRENT on OrangePi One To: Emmanuel Vadot References: <9e04f3cf-ddce-1b53-b9d6-2fe05ad1cc25@paranoici.org> <20170502105507.4c51a7323bd01903e402f551@bidouilliste.com> <64893df0-f9f7-d24b-8644-bc84824fc657@paranoici.org> <20170502132311.26aa210165fc10f5435def80@bidouilliste.com> Cc: freebsd-arm@freebsd.org From: aggaz Message-ID: Date: Tue, 2 May 2017 15:10:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170502132311.26aa210165fc10f5435def80@bidouilliste.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 13:10:52 -0000 Sorry, I had the same error even with another dtb file (from nanopi, the one I always used until now). I never noticed this and I don't know if this is related to the dtb files or to my own OrangePi/FreeBSD-image or SD-card. I just did an "fsck" and the error seem corrected... for now. FYI, these are the messages I goot during the booting process when the "glitch" showed up: ====================================== U-Boot SPL 2017.01-rc3 (Apr 14 2017 - 05:00:34) DRAM: 512 MiB Trying to boot from MMC1 U-Boot 2017.01-rc3 (Apr 14 2017 - 05:00:34 +0000) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi One DRAM: 512 MiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: phy interface0 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found FreeBSD U-Boot Loader (bin) reading ubldr.bin 237360 bytes read in 34 ms (6.7 MiB/s) ## Starting application at 0x42000000 ... Consoles: U-Boot console Compatible U-Boot API signature found @0x5bf41100 FreeBSD/armv6 U-Boot loader, Revision 1.2 (Tue Apr 25 13:04:20 CEST 2017 orangepi@anuro) DRAM: 512MB MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Number of U-Boot devices: 1 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=0x6a9880+0x1a6780 syms=[0x4+0xba5b0+0x4+0xaab13] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/dtb/sun8i-h3-orangepi-one.dtb size=0x5087 Loaded DTB from file 'sun8i-h3-orangepi-one.dtb'. Kernel entry at 0x42200100... Kernel args: (null) 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 r317402: Tue Apr 25 13:04:13 CEST 2017 orangepi@anuro:/media/ventello/src/crochet/work/obj/arm.armv6/media/ventello/src/freebsd/sys/ALLWINNER arm FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) 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/32B 2-way instruction cache Read-Alloc Cache level 2: 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc real memory = 536870912 (512 MB) avail memory = 509968384 (486 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs arc4random: no preloaded entropy cache random: entropy device external interface kbd0 at kbdmux0 ofwbus0: aw_ccu0: on ofwbus0 clk_fixed0: on aw_ccu0 clk_fixed1: on aw_ccu0 clk_fixed2: on aw_ccu0 aw_gate0: mem 0x1f01428-0x1f0142b on aw_ccu0 aw_modclk0: mem 0x1f01454-0x1f01457 on aw_ccu0 simplebus0: on ofwbus0 aw_ccung0: mem 0x1c20000-0x1c203ff on simplebus0 aw_reset0: mem 0x1f014b0-0x1f014b3 on simplebus0 iichb0: mem 0x1f02400-0x1f027ff irq 34 on simplebus0 iichb0: could not find clock device_attach: iichb0 attach returned 2 regfix0: on ofwbus0 regfix1: on ofwbus0 regfix2: on ofwbus0 iichb0: mem 0x1f02400-0x1f027ff irq 34 on simplebus0 iichb0: could not find clock device_attach: iichb0 attach returned 2 aw_sid0: mem 0x1c14000-0x1c143ff on simplebus0 iichb0: mem 0x1f02400-0x1f027ff irq 34 on simplebus0 iichb0: could not find clock device_attach: iichb0 attach returned 2 awusbphy0: mem 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803,0x1c1c800-0x1c1c803,0x1c1d800-0x1c1d803 on simplebus0 iichb0: mem 0x1f02400-0x1f027ff irq 34 on simplebus0 iichb0: could not find clock device_attach: iichb0 attach returned 2 gic0: mem 0x1c81000-0x1c81fff,0x1c82000-0x1c82fff,0x1c84000-0x1c85fff,0x1c86000-0x1c87fff irq 28 on simplebus0 gic0: pn 0x1, arch 0x2, rev 0x1, implementer 0x43b irqs 160 iichb0: mem 0x1f02400-0x1f027ff irq 34 on simplebus0 iichb0: could not find clock device_attach: iichb0 attach returned 2 gpio0: mem 0x1c20800-0x1c20bff irq 14,15 on simplebus0 gpiobus0: on gpio0 gpio1: mem 0x1f02c00-0x1f02fff irq 32 on simplebus0 gpiobus1: on gpio1 iichb0: mem 0x1f02400-0x1f027ff irq 34 on simplebus0 iichb0: could not find clock device_attach: iichb0 attach returned 2 iichb0: mem 0x1f02400-0x1f027ff irq 34 on simplebus0 iichb0: could not find clock device_attach: iichb0 attach returned 2 generic_timer0: irq 0,1,2,3 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 rtc0: mem 0x1f00000-0x1f00053 irq 29,30 on simplebus0 iichb0: mem 0x1f02400-0x1f027ff irq 34 on simplebus0 iichb0: could not find clock device_attach: iichb0 attach returned 2 cpulist0: on ofwbus0 cpu0: on cpulist0 cpufreq_dt0: on cpu0 cpufreq_dt0: no regulator for cpu@0 device_attach: cpufreq_dt0 attach returned 6 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 a31dmac0: mem 0x1c02000-0x1c02fff irq 4 on simplebus0 a10_mmc0: mem 0x1c0f000-0x1c0ffff irq 5 on simplebus0 mmc0: on a10_mmc0 ehci0: mem 0x1c1d000-0x1c1d0ff irq 12 on simplebus0 usbus0: EHCI version 0.0 usbus0 on ehci0 ohci0: mem 0x1c1d400-0x1c1d4ff irq 13 on simplebus0 usbus1 on ohci0 gpioc0: on gpio0 aw_wdog0: mem 0x1c20ca0-0x1c20cbf irq 20 on simplebus0 uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 21 on simplebus0 uart0: console (115384,n,8,1) gpioc1: on gpio1 awg0: mem 0x1c30000-0x1c30103,0x1c00030-0x1c00033 irq 33 on simplebus0 awg0: soft reset timed out device_attach: awg0 attach returned 60 iichb0: mem 0x1f02400-0x1f027ff irq 34 on simplebus0 iichb0: could not find clock device_attach: iichb0 attach returned 2 aw_thermal0: mem 0x1c25000-0x1c253ff irq 35 on simplebus0 gpioled0: on ofwbus0 cryptosoft0: Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub_attach: getting USB 2.0 HUB descriptor failed,error=USB_ERR_SHORT_XFER device_attach: uhub0 attach returned 6 usbus0: Root HUB problem, error=USB_ERR_NO_ROOT_HUB ugen1.1: at usbus1 uhub0: on usbus1 uhub_attach: getting USB 2.0 HUB descriptor failed,error=USB_ERR_SHORT_XFER device_attach: uhub0 attach returned 6 usbus1: Root HUB problem, error=USB_ERR_NO_ROOT_HUB mmcsd0: 16GB at mmc0 50.0MHz/4bit/65535-block Release APs WARNING: WITNESS option enabled, expect reduced performance. arc4random: no preloaded entropy cache Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... arc4random: no preloaded entropy cache WARNING: / was not properly dismounted arc4random: no preloaded entropy cache Setting hostuuid: a76a4e01-f668-11de-88ec-1972d578a651. Setting hostid: 0xdd9cc20e. No suitable dump device was found. Starting file system checks: ** SU+J Recovering /dev/mmcsd0s2a ** Reading 4194304 byte journal from inode 4. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. ** 4 journal records in 1024 bytes for 12.50% utilization ** Freed 4 inodes (0 dirs) 0 blocks, and 0 frags. ***** FILE SYSTEM MARKED CLEAN ***** Mounting local filesystems:. rm: devd.pipe: Bad file descriptor rm: devd.seqpacket.pipe: Bad file descriptor rm: ld-elf-soft.so.hints: Bad file descriptor rm: log: Bad file descriptor rm: logpriv: Bad file descriptor ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib random: unblocking device. Soft Float compatibility ldconfig path: ldconfig: Cannot stat "/var/run/ld-elf-soft.so.hints": Bad file descriptor Setting hostname: partuallo. Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED Feeding entropy: . Starting Network: lo0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21 Starting devd. Starting pflog. panic: softdep_setup_inomapdep: dependency 0xc309d700 for newinode already exists cpuid = 0 time = 1262304032 KDB: stack backtrace: $a.4() at $a.4 pc = 0xc06ece1c lr = 0xc025a71c (db_trace_self_wrapper+0x30) sp = 0xde0ed720 fp = 0xde0ed838 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc025a71c lr = 0xc0410314 (vpanic+0x148) sp = 0xde0ed840 fp = 0xde0ed860 r4 = 0x00000100 r5 = 0x00000001 r6 = 0xc07a8d57 r7 = 0xc09b32c8 vpanic() at vpanic+0x148 pc = 0xc0410314 lr = 0xc04103b0 (kproc_shutdown) sp = 0xde0ed868 fp = 0xde0ed86c r4 = 0xc2ba4e00 r5 = 0xc3133000 r6 = 0x0001e91d r7 = 0xc3132000 r8 = 0xc31d2cb0 r9 = 0x00000000 r10 = 0xc331b000 kproc_shutdown() at kproc_shutdown pc = 0xc04103b0 lr = 0xc067cf6c (softdep_setup_inomapdep+0x294) sp = 0xde0ed874 fp = 0xde0ed8b0 r4 = 0xc04103b0 r5 = 0xde0ed874 softdep_setup_inomapdep() at softdep_setup_inomapdep+0x294 pc = 0xc067cf6c lr = 0xc066463c (ffs_nodealloccg+0x75c) sp = 0xde0ed8b8 fp = 0xde0ed918 r4 = 0x0000141d r5 = 0x00000002 r6 = 0x000081a4 r7 = 0xcd430000 r8 = 0xcd4300a8 r9 = 0xc3133000 r10 = 0x00001580 ffs_nodealloccg() at ffs_nodealloccg+0x75c pc = 0xc066463c lr = 0xc0660880 (ffs_hashalloc+0x7c) sp = 0xde0ed920 fp = 0xde0ed948 r4 = 0xc31d2cb0 r5 = 0xc0663ee0 r6 = 0x00000000 r7 = 0x0001d52a r8 = 0xc3133000 r9 = 0x00000002 r10 = 0x000081a4 ffs_hashalloc() at ffs_hashalloc+0x7c pc = 0xc0660880 lr = 0xc06637c8 (ffs_valloc+0x130) sp = 0xde0ed950 fp = 0xde0ed9d0 r4 = 0x00000000 r5 = 0xc31d2cb0 r6 = 0x0001d52a r7 = 0xc2ee8480 r8 = 0xc3038d00 r9 = 0x000081a4 r10 = 0xc3133000 ffs_valloc() at ffs_valloc+0x130 pc = 0xc06637c8 lr = 0xc06abe0c (ufs_makeinode+0x98) sp = 0xde0ed9d8 fp = 0xde0edb28 r4 = 0xc2ee8480 r5 = 0x000081a4 r6 = 0xc0663698 r7 = 0xc31d2cb0 r8 = 0x00020a00 r9 = 0xde0edcf0 r10 = 0xde0edd08 ufs_makeinode() at ufs_makeinode+0x98 pc = 0xc06abe0c lr = 0xc06a7f78 (ufs_create+0x3c) sp = 0xde0edb30 fp = 0xde0edb40 r4 = 0xde0edc24 r5 = 0xc06a7fbc r6 = 0xffffffff r7 = 0xde0edc28 r8 = 0x00020a00 r9 = 0x00000000 r10 = 0x00000000 ufs_create() at ufs_create+0x3c pc = 0xc06a7f78 lr = 0xc07400e4 (VOP_CREATE_APV+0xfc) sp = 0xde0edb48 fp = 0xde0edb60 r4 = 0xde0edc24 r5 = 0xc0897b68 VOP_CREATE_APV() at VOP_CREATE_APV+0xfc pc = 0xc07400e4 lr = 0xc04ec520 (vn_open_cred+0x284) sp = 0xde0edb68 fp = 0xde0edc58 r4 = 0xde0edca0 r5 = 0xde0edcf0 r6 = 0x00000000 r7 = 0x00000602 vn_open_cred() at vn_open_cred+0x284 pc = 0xc04ec520 lr = 0xc04ec294 (vn_open+0x24) sp = 0xde0edc60 fp = 0xde0edc68 r4 = 0xc3196a80 r5 = 0x00000012 r6 = 0x000001b6 r7 = 0xde0edca0 r8 = 0x00000000 r9 = 0x20611080 r10 = 0xde0edc90 vn_open() at vn_open+0x24 pc = 0xc04ec294 lr = 0xc04e5538 (kern_openat+0x204) sp = 0xde0edc70 fp = 0xde0edd70 kern_openat() at kern_openat+0x204 pc = 0xc04e5538 lr = 0xc04e532c (sys_open+0x28) sp = 0xde0edd78 fp = 0xde0edd80 r4 = 0xc0a2d8d8 r5 = 0xc317bac8 r6 = 0x00000000 r7 = 0xc0a48880 r8 = 0x00000000 r9 = 0xde0edda0 r10 = 0xc3196a80 sys_open() at sys_open+0x28 pc = 0xc04e532c lr = 0xc070f0a0 ($a.6+0x1ac) sp = 0xde0edd88 fp = 0xde0ede40 $a.6() at $a.6+0x1ac pc = 0xc070f0a0 lr = 0xc06efad0 (swi_exit) sp = 0xde0ede48 fp = 0xbfbfeda8 r4 = 0x202821c8 r5 = 0x00000008 r6 = 0x00000000 r7 = 0x00000005 r8 = 0x206129e3 r9 = 0x00014f94 r10 = 0x00000007 swi_exit() at swi_exit pc = 0xc06efad0 lr = 0xc06efad0 (swi_exit) sp = 0xde0ede48 fp = 0xbfbfeda8 KDB: enter: panic [ thread pid 246 tid 100070 ] Stopped at $d.8: ldrb r15, [r15, r15, ror r15]! db> ====================================== Regards Aggaz Il 02/05/2017 13:23, Emmanuel Vadot ha scritto: > On Tue, 2 May 2017 12:43:41 +0200 > aggaz wrote: > >> Dear Emmanuel, >> >> In the last days I found and tried the dts file you are referring to >> (the one in sys/gnu/.../...). >> I compiled it using crochet, and I can confirm that it boots, it >> supports USB but not Ethernet. >> >> It also seems to me that it is less stable than the other two I tried >> (the one for OrangePi Plus 2E and the one from NanoPi Neo). > > Less stable in what way ? > >> Maybe it is not related to the dts, but I saw several random glitches >> after boot that make me think that this Linux-imported dts is not 100% >> compatible. > > Random glitches of what exactly ? > >> I hope you find the dts with both ethernet and usb. >> >> A question: would it be possible to integrate the ethernet portion of >> the dts for NanoPi to the dts for OrangePiPlus 2E? > > I don't think I have the Plus 2E so I won't be able to test, I think > the only difference would be the regulator for the PHY (or the usage of > internal PHY). > >> I am trying to do so in the last days, but I do not really understand >> how to write a DTS file... >> >> I am also looking for documentation, without so much luck, if you have >> some link/book/manual you feel like sharing, please do. > > There is none afaik, just read the binding docs from the Linux kernel > Documentation. > >> Regards >> Aggaz > > Cheers, > >> Il 02/05/2017 10:55, Emmanuel Vadot ha scritto: >>> On Sun, 30 Apr 2017 12:27:04 +0200 >>> aggaz wrote: >>> >>>> Dear list, >>>> >>>> as I previously wrote, I am trying to use FreeBSD 12-CURRENT on OrangePi >>>> One by using crochet. >>>> >>>> One problem is that there are no dtb files available specific for this >>>> board. >>> >>> There is one in sys/gnu/dts, I was sure that I added it to the list of >>> DTS we compile but ... >>> >>>> Now I compared two dtb files for the same SoC (H3): one for NanoPi Neo >>>> (/boot/dtb/nanopi-neo.dtb) and one for OrangePi Plus 2E >>>> (/boot/dtb/orangepi-plus-2e.dtb). >>>> >>>> Both makes the board boot fine without issues, but: >>>> >>>> 1) dtb file for NanoPi Neo makes the network interface available and >>>> working, but not the USB port. >>>> >>>> 2) dtb file for OrangePi Plus 2E makes the USB port available and >>>> working, but not the network interface. >>> >>> Please note that ethernet DTS bindings aren't standardized yet and >>> since I don't want us to heavily patches the DTS or derive to much from >>> the Linux one if I add the OrangePi One DTS to the build it will >>> probably be without ethernet support. >>> >>> Anyway, I have one somewhere with USB and ethernet support, I'll look >>> to commit/share that soon. >>> >>>> >>>> At this point I don't really know what I can do to make both interfaces >>>> working at the same time, and I am writing this to ask you some suggestions. >>>> >>>> Any idea would be greatly appreciated. >>>> >>>> Regards >>>> Aggaz >>>> _______________________________________________ >>>> freebsd-arm@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >>> >>> > > From owner-freebsd-arm@freebsd.org Tue May 2 16:30: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 4C8EBD5B623 for ; Tue, 2 May 2017 16:30:02 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.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 134A2874 for ; Tue, 2 May 2017 16:30:01 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6AB012085C for ; Tue, 2 May 2017 12:30:00 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Tue, 02 May 2017 12:30:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=gLmyHkugIxZgLK2lkz 6Dfl3o7EKhT3cMqV3dx7zRLzs=; b=hI4efGdRrk6pLwxTSrUUD/02zt3FPKWWCu /TPNaRnVY8PNclC8GzWM6tPsodoWd8+VSYDDUmrfnOzbUstuiZ7+smVlrq9LvbUg g0fyMO1hhzKMG04nxLBnGqxynbQ5wQ6ToyajY7TF0UA9aO8hSAiVdL6AbX0U4ikF C4DM8J0gAxBJ03mYU+2jgRvW5j3bkvIRUdQAFqZN6qJ3+vGbL9Q5IQEhonGkUD75 hc9Yv5ZQmyYzm8+a+VDwmELG9XTQVM9tnbi21wnyZllz7zuTPhoLQGFytq4eh0Md GzYknuRPHPCbCHfUMBLHitWRGFb3WXJsB7k+2op5ezqnoaJtxPow== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=gLmyHkugIxZgLK2lkz6Dfl3o7EKhT3cMqV3dx7zRLzs=; b=jOuXrcLZ 7N/MeV8+9Kr8OfocV62nB2E92JVwBZWeAtMZIBwRphcSlcUsuBUZIZWHxncb/CZu 2hIrKusjjX6G828dknMCRL/q+0D2s6v6k1G53s9hdnMqr+/gp5E7Vyt5zOz1Y88Q qvA/5r7zUEGSLDIldE1uVScELOzp7H9CVb6H1I+soTwlGicWCsLBwWJFiG3VM3dZ Z3C4B2IchAwZtiAkh36R+F4LHU+7OvdDypWfvkG8VwcinPuEUFJHnqMaFDm1dPsb cMLACznnI8dKot9Bv4efWmkACeCimv02dsOiHZOB4LJD51KNjwsQ5rAqcy39YgJG rfraPhRcPNGclQ== X-ME-Sender: X-Sasl-enc: omNdMWro+O99Ad0SoWc6IciL6qkIGk6gWEDbgBBoln2M 1493742599 Received: from [192.168.1.230] (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id D0BAA2475D for ; Tue, 2 May 2017 12:29:59 -0400 (EDT) Subject: Re: lock when building llvm37 on RPI3 To: freebsd-arm@freebsd.org References: <0b4b8a6f-f008-4892-a7c1-73fab2a79030@bsd.com.br> <4085737d-af52-3f21-c593-3be249b59d46@zyxst.net> <9d7569cd-e2fd-0e6b-225f-bf800eae3e25@bsd.com.br> From: tech-lists Message-ID: Date: Tue, 2 May 2017 17:29:53 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <9d7569cd-e2fd-0e6b-225f-bf800eae3e25@bsd.com.br> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB 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, 02 May 2017 16:30:02 -0000 On 02/05/2017 11:48, Otacílio wrote: > Hello > > 1. No, I not installed ccache previously. Thank you by your hint. > > 2. Yes. I'm using a external USB hard disk (Seagate, 500 GB auto > powered). /usr/obj /usr/ports and /usr/src is mounted there. > > 3. No. I will do it also. > > Unhappily I was using a NODEBUG kernel and no hint about the deadlock > was printed. Maybe the deadlock can be caused by the micro SD HC card > used but I can not affirm. > > I give another try and this time I got a kernel panic at > reclaim_pv_chunk http://imgur.com/XLiziq1 I'm unable to parse stack traces, but I know that with microsd cards, that they can go wrong in odd ways. If the kernel tries to read something essential to itself and can't, that can cause a panic. So the next thing i'd try is another, new, microsd card. -- J. From owner-freebsd-arm@freebsd.org Tue May 2 17:58:32 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 9C530D5B543 for ; Tue, 2 May 2017 17:58:32 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (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 3C14C1D83 for ; Tue, 2 May 2017 17:58:32 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: by mail-wr0-x241.google.com with SMTP id 6so18913427wrb.1 for ; Tue, 02 May 2017 10:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:references:to:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Pa+/X/fUu/9BCcI7y07yaxlNiW9j73R1BJlyCIzEN2E=; b=QeNAs4RELLt/dyuYMRSR0hCXIOfV3PSh6bZbPxffRJweXhzQtkxyPdu501PjoaBuSA P2B0T7Ncg0gBIJixBK5ukFpBCPb85ayQ03WnB2SI+1fDabpE17+xZ58eoJSn/nM0w53i eVIVtqiOxhN1s6ixa9eh14hDSRm0BZc+JcHR9ERZ1mDpeTvwb9h6uNOf4bQNbJbn70gl G2GryCMQ2y/4y0tW0GhBhKZDGBRT2hhvvmziFDc6ztAe70MoDXAHD+tFe/dsL35QnlXt qAjcyYixr4Cy3cSsJEyLGdWWDTztVs2Ge4K+8qHWiKZJDILF1UeagGVBqD6D9xXlG8Uu DQKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:references:to:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Pa+/X/fUu/9BCcI7y07yaxlNiW9j73R1BJlyCIzEN2E=; b=LUdHGoTiHMflQ+RB0u5BAsNGmDFe5CUcdKV8Mu8qXZ7m17z5qR494VHorf5x36jkCQ 1IQs9i753n2ICoB2ZHvONM32MF+3V8lxxWzZO3cf1lHeYYHH0JX/0yWhtJp9isjc+LPW 0pL/W8HH78T5lxn7du+Gw6isAl+/W5WesMme5lknyrRf+fRhSfCypwNIO5ZxmlQGF0z6 yHxn5LcM3d7tliQleCW1JrIRKfU51br7APsCEJkv9IqQqB0raFTeH0pBcdc4gDpbVhRy IYTlKqsdez/UKQmERydeVmgkah2MWMXNuCLK96Dy6CjcRiDVzOveHTNk6uw/jFq32qXQ 7ywg== X-Gm-Message-State: AN3rC/6LCREObUhoqL6iCOE+O/QPSRDJAI/EdXng3u3ZKqGEXwD2dd1s D8xMuR6KaO/sZA== X-Received: by 10.223.136.75 with SMTP id e11mr20956878wre.14.1493747908996; Tue, 02 May 2017 10:58:28 -0700 (PDT) Received: from ?IPv6:2a02:aa16:1101:d800::5? ([2a02:aa16:1101:d800::5]) by smtp.googlemail.com with ESMTPSA id l45sm14794908wre.2.2017.05.02.10.58.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 10:58:27 -0700 (PDT) From: Mattia Rossi X-Google-Original-From: Mattia Rossi Reply-To: mattia.rossi.mailinglists@gmail.com Subject: Re: OrangePi-Plus-2 boot process hangs in ubldr.bin References: <20170502105007.0424f8cb7c8021951bf04495@bidouilliste.com> To: Emmanuel Vadot , Warner Losh , ARM Message-ID: <196d9b83-f346-e51f-3ca7-4bc9b3a44a4b@gmail.com> Date: Tue, 2 May 2017 19:58:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170502105007.0424f8cb7c8021951bf04495@bidouilliste.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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, 02 May 2017 17:58:32 -0000 On 02/05/17 10:50, Emmanuel Vadot wrote: > On Sun, 30 Apr 2017 13:07:23 +0200 > Mattia Rossi wrote: > >> Hi all, > Hello, > >> I've tried to upgrade u-boot on the OrangePi-Plus-2 (not the 2e) from >> mainline u-boot and on the outside it looks fine. > When you say mainline, what exact version did you took ? > I assume you took some patches also as it seems that your u-boot have > API support. I took the latest git version (latest at the time: v2017.05-rc2-129-g1e6776000e) from http://git.denx.de/u-boot.git As I understand from the description of u-boot-master in ports, all changes made by Warner have been merged upstream, so this version should have all the necessary patches. API support can simply be enabled in the config. Oh one additional info: I built it on a linux machine using gcc: gcc version 5.4.0 (Gentoo 5.4.0-r3 p1.3, pie-0.6.5) Target: armv6j-hardfloat-linux-gnueabi Maybe that's some detail you need and I missed to write ;-) > >> U-boot loads, and it boots ubldr.bin. >> >> I'm using the orangepi-plus-2e.dtb as it has been working well for this >> board before (It all used to work). >> >> Now ubldr can't boot the kernel though, and I don't know why. I've >> rebuilt ubldr, world and kernel from svn. Revision number is 317594 >> >> Any help would be appreciated >> >> The output before it stops is: >> >> U-Boot SPL 2017.05-rc2-00061-g12af9399e7 (Apr 25 2017 - 19:27:44) >> DRAM: 2048 MiB >> Trying to boot from MMC1 >> >> >> U-Boot 2017.05-rc2-00061-g12af9399e7 (Apr 25 2017 - 19:27:44 +0200) >> Allwinner Technology >> >> CPU: Allwinner H3 (SUN8I 1680) >> Model: Xunlong Orange Pi Plus 2E >> I2C: ready >> DRAM: 2 GiB >> MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 >> In: serial >> Out: serial >> Err: serial >> Net: phy interface7 >> eth0: ethernet@1c30000 >> starting USB... >> USB0: USB EHCI 1.00 >> USB1: USB OHCI 1.0 >> USB2: USB EHCI 1.00 >> USB3: USB OHCI 1.0 >> USB4: USB EHCI 1.00 >> USB5: USB OHCI 1.0 >> scanning bus 0 for devices... 1 USB Device(s) found >> scanning bus 2 for devices... 1 USB Device(s) found >> scanning bus 4 for devices... 1 USB Device(s) found >> scanning usb for storage devices... 0 Storage Device(s) found >> Hit any key to stop autoboot: 0 >> Booting from: mmc 0 ubldr.bin >> reading ubldr.bin >> 237168 bytes read in 34 ms (6.7 MiB/s) >> ## No elf image at address 0x42000000 >> ## Starting application at 0x42000000 ... >> Consoles: U-Boot console >> Compatible U-Boot API signature found @0xbbf3f690 >> >> FreeBSD/armv6 U-Boot loader, Revision 1.2 >> (Sat Apr 29 19:16:42 CEST 2017 root@freebsd101) >> >> DRAM: 2048MB >> MMC Device 2 not found >> MMC Device 3 not found >> Number of U-Boot devices: 2 >> U-Boot env: loaderdev='mmc 0' >> Found U-Boot device: disk >> Checking unit=0 slice= partition=... good. >> Booting from disk0s2: >> /boot/kernel/kernel data=0x6a82c0+0x1a7d40 syms=[0x4+0xba030+0x4+0xaa532] >> >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> /boot/dtb/orangepi-plus-2e.dtb size=0x6326 >> Loaded DTB from file 'orangepi-plus-2e.dtb'. >> Kernel entry at 0x42200100... >> Kernel args: (null) > This is probably a cache problem, the u-boot from ports (using imp@ > branch on github) do take care of that. Thanks for pointing that out, but could you expand on this? As I said before, I think all the patches were merged upstream. I do have a lot of cache configuration options which can be selected though. Does it have something to do with: Symbol: BLOCK_CACHE [=n] │ Type : boolean │ Prompt: Use block device cache │ Location: │ (1) -> Device Drivers │ Defined at drivers/block/Kconfig:31 or Symbol: SYS_L2CACHE_OFF [=n] or Symbol: SYS_MIPS_CACHE_INIT_RAM_LOAD [=n] ? > >> The u-boot environment looks like this: >> >> => printenv >> Fatboot=echo Booting from: ${fatdev} ${bootfile}; fatload ${fatdev} >> ${kernel_addr_r} ${bootfile} && bootelf || go ${kernel_addr_r}; >> SetupFatdev=env exists fatdev || env set fatdev 'mmc 0'; >> api_address=bbf3f690 >> baudrate=115200 >> bootcmd=run Fatboot >> bootfile=ubldr.bin >> bootm_size=0xa000000 >> console=ttyS0,115200 >> eth1addr=12:81:5a:66:27:6f >> ethact=ethernet@1c30000 >> ethaddr=02:81:5a:66:27:6f >> fatdev=mmc 0 >> fdt_addr_r=0x43000000 >> fdtcontroladdr=bbf39b68 >> fdtfile=orangepi-plus-2e.dtb >> ipaddr=192.168.0.200 >> kernel_addr_r=0x42000000 >> loaderdev=mmc 0 >> preboot=usb start; env exists bootfile || env set bootfile ubldr.bin; >> env exists SetupFatdev && run SetupFatdev; env exists UserPreboot && run >> UserPreboot; >> pxefile_addr_r=0x43200000 >> ramdisk_addr_r=0x43300000 >> scriptaddr=0x43100000 >> serial#=02c000815a66276f >> stderr=serial,vga >> stdin=serial,usbkbd >> stdout=serial,vga >> >> Environment size: 898/131068 bytes >> => >> >> >> The loader variables are the following: >> >> loader> show >> LINES=24 >> autoboot_delay=10 >> bootfile=kernel >> console=uboot >> currdev=disk0s2: >> interpret=OK >> kernel=kernel >> kernelname=/boot/kernel/kernel >> loaddev=disk0s2: >> loader_conf_files=/boot/loader.conf /boot/loader.conf.local >> module_path=/boot/kernel;/boot/kernel;/boot/modules;/boot/dtb >> prompt=loader> >> twiddle_divisor=1 >> loader> >> >> >> The filesystem can be found: >> >> loader> ls >> / >> d .snap >> COPYRIGHT >> d bin >> d boot >> d dev >> d etc >> d lib >> d libexec >> d media >> d mnt >> d proc >> d rescue >> d root >> d sbin >> l sys >> d tmp >> d usr >> d var >> loader> ls boot >> boot >> d kernel >> d defaults >> d dtb >> d firmware >> d modules >> d zfs >> loader.efi >> boot1.efi >> boot1.efifat >> menu.rc.sample >> ubldr >> ubldr.bin >> beastie.4th >> brand.4th >> brand-fbsd.4th >> check-password.4th >> color.4th >> delay.4th >> frames.4th >> loader.4th >> loader.help >> logo-beastie.4th >> logo-beastiebw.4th >> menu.4th >> logo-fbsdbw.4th >> logo-orb.4th >> logo-orbbw.4th >> menu-commands.4th >> menusets.4th >> screen.4th >> shortcuts.4th >> support.4th >> version.4th >> loader.rc >> efi.4th >> loader> >> >> Other info from ubldr: >> >> loader> devinfo >> MMC Device 2 not found >> MMC Device 3 not found >> U-Boot devices: >> device info (0): >> cookie = 0xbbf3f0b8 >> type = 0x00000082 >> type = MMC >> blk size = 512 >> blk count = 30318592 >> >> device info (1): >> cookie = 0xbbf3f4c0 >> type = 0x00000082 >> type = MMC >> blk size = 512 >> blk count = 30535680 >> >> loader> sysinfo >> U-Boot system info: >> sys info: >> clkbus = 0 MHz >> clkcpu = 0 MHz >> bar = 0x00000000 >> --- >> start = 0x40000000 >> size = 0x80000000 >> type = DRAM >> --- >> loader> >> >> U-boot variables are found in ubldr: >> >> loader> ubenv show >> uboot.preboot=usb start; env exists bootfile || env set bootfile >> ubldr.bin; env exists SetupFatdev && run SetupFatdev; env exists >> UserPreboot && run UserPreboot; >> uboot.bootm_size=0xa000000 >> uboot.loaderdev=mmc 0 >> uboot.fatdev=mmc 0 >> uboot.fdtcontroladdr=bbf39b68 >> uboot.serial#=02c000815a66276f >> uboot.pxefile_addr_r=0x43200000 >> uboot.eth1addr=12:81:5a:66:27:6f >> uboot.api_address=bbf3f690 >> uboot.scriptaddr=0x43100000 >> uboot.ethaddr=02:81:5a:66:27:6f >> uboot.fdt_addr_r=0x43000000 >> uboot.stdin=serial,usbkbd >> uboot.baudrate=115200 >> uboot.ethact=ethernet@1c30000 >> uboot.bootcmd=run Fatboot >> uboot.kernel_addr_r=0x42000000 >> uboot.filesize=39e70 >> uboot.bootfile=ubldr.bin >> uboot.fdtfile=orangepi-plus-2e.dtb >> uboot.fileaddr=42000000 >> uboot.stdout=serial,vga >> uboot.ramdisk_addr_r=0x43300000 >> uboot.Fatboot=echo Booting from: ${fatdev} ${bootfile}; fatload >> ${fatdev} ${kernel_addr_r} ${bootfile} && bootelf || go ${kernel_addr_r}; >> uboot.console=ttyS0,115200 >> uboot.SetupFatdev=env exists fatdev || env set fatdev 'mmc 0'; >> uboot.ipaddr=192.168.0.200 >> uboot.stderr=serial,vga >> loader> >> >> Kernel and modules seem loaded... >> >> loader> lsmod >> 0x42200000: /boot/kernel/kernel (elf kernel, 0x9b456c) >> modules: aw_ccung.1 aw_ccu.1 aw_reset.1 a10hdmiaudio.1 a10hdmi.1 >> aw_thermal.1 aw_sid.1 axp81x.1 axp2xx.1 rsb.1 awusbphy.1 a10codec.1 >> ufs.1 krpc.1 cryptosoft.1 crypto.1 nfslockd.1 nfssvc.1 nfslock.1 ipsec.1 >> ether.1 zlib.1 aio.1 sysvshm.1 sysvsem.1 sysvmsg.1 acl_posix1e.1 >> acl_nfs4.1 kernel.1200030 cd9660.1 g_part.0 g_flashmap.0 pseudofs.1 >> procfs.1 nfscl.1 nfs.1 nfscommon.1 msdosfs.1 videomode.1 usb_quirk.1 >> ums.1 ukbd.1 uhub.1 usb.1 umass.1 midi.1 sound.5 random_device.1 >> random_harvestq.1 ofwbus.1 null.1 mmc.3 mii_bitbang.1 miibus.1 mem.1 >> ofw_iicbus.1 iicbus.1 iic.1 ofw_gpiobus.1 gpioc.1 gpiobus.1 fbd.1 >> ofw_regulator_bus.1 clk_fixed.1 ofw_clkbus.1 ahci.1 cam.1 >> >> Thanks, >> >> Mat >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Tue May 2 21:29: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 E0050D5A671 for ; Tue, 2 May 2017 21:29:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-62.reflexion.net [208.70.210.62]) (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 9E68A17E8 for ; Tue, 2 May 2017 21:29:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18928 invoked from network); 2 May 2017 21:22:27 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 May 2017 21:22:27 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 02 May 2017 17:22:27 -0400 (EDT) Received: (qmail 13728 invoked from network); 2 May 2017 21:22:26 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 May 2017 21:22:26 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 11BC0EC7A6F; Tue, 2 May 2017 14:22:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots but gets some panics] From: Mark Millard In-Reply-To: Date: Tue, 2 May 2017 14:22:25 -0700 Cc: "O. Hartmann" , Tom Vijlbrief Content-Transfer-Encoding: 7bit Message-Id: <9E66D0B3-3682-49DD-A792-95E29F9DC55C@dsl-only.net> References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> To: freebsd-arm , FreeBSD Current , Andrew Turner , Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 21:29:09 -0000 It turns out that the bt's from the example panics are repeatable for the pc and lr sequence involved (but not the specific sp's and fp's involved). I report this in case it suggests anything. I'll note that the build had a production style kernel for a build of -r317015 . The first type of panic actually a back to back sequence of two bt's, this is the sleeping-thread type pf example. The second type is just one bt by itself. There is one variable lr in the bt for the sleeping-thread type of example (the first type of panic of the two shown later, the one with back-to-back bt's): 131,133c131,133 < handle_el0_sync() at 0x40040070 < pc = 0xffff0000006079e8 lr = 0x0000000040040070 < sp = 0xffff000065dfdba0 fp = 0x0000ffffffffeb00 --- > handle_el0_sync() at 0x40044490 > pc = 0xffff0000006079e8 lr = 0x0000000040044490 > sp = 0xffff000040229ba0 fp = 0x0000ffffffffe3d0 Otherwise the two bt's in the example match for the pc/lr sequence. I only have the two examples of this type to compare so far (one diff). I have 3 examples of the second type and they had no such variation. One thing in common to all 5 of these examples is the sequence: data_abort() at handle_el1h_sync+0x70 lr = 0xffff000000607870 handle_el1h_sync() at pmap_remove_pages+0x2a8 pc = 0xffff000000607870 lr = 0xffff0000006175d4 pmap_remove_pages() being involved in each example. I'm not saying that I can cause any panics at will, but when either of the two types happen the bt is (mostly) stable for the pc and lr sequence and that short sequence above is involved. I have seen one other type of panic but I did not manage to record a bt for it yet. It involved the instruction cache instead of arm64_dcache_wb_range . I quote the prior reported example bt's below. On 2017-May-2, at 5:24 AM, Mark Millard wrote: > On 2017-May-2, at 3:37 AM, Mark Millard wrote: > >> On 2017-May-2, at 2:53 AM, Mark Millard wrote: >> >> . . . >> FYI: >> >> I do sometimes get things like: >> >> >> System shutdown time has arrived >> Apr 30 19:43:15 ODC2FBSD shutdown: power-down by root: >> Sleeping thread (tid 100093, pid 708) owns a non-sleepable lock >> KDB: stack backtrace of thread 100093: >> sched_switch() at mi_switch+0x100 >> pc = 0xffff000000347d44 lr = 0xffff000000327358 >> sp = 0xffff000040237e00 fp = 0xffff000040237e20 >> >> mi_switch() at sleepq_wait+0x3c >> pc = 0xffff000000327358 lr = 0xffff00000036c174 >> sp = 0xffff000040237e30 fp = 0xffff000040237e50 >> >> sleepq_wait() at _sleep+0x29c >> pc = 0xffff00000036c174 lr = 0xffff000000326c7c >> sp = 0xffff000040237e60 fp = 0xffff000040237ee0 >> >> _sleep() at vm_page_sleep_if_busy+0xb0 >> pc = 0xffff000000326c7c lr = 0xffff0000005cfcf4 >> sp = 0xffff000040237ef0 fp = 0xffff000040237f10 >> >> vm_page_sleep_if_busy() at vm_fault_hold+0xcc8 >> pc = 0xffff0000005cfcf4 lr = 0xffff0000005ba17c >> sp = 0xffff000040237f20 fp = 0xffff000040238070 >> >> vm_fault_hold() at vm_fault+0x70 >> pc = 0xffff0000005ba17c lr = 0xffff0000005b9464 >> sp = 0xffff000040238080 fp = 0xffff0000402380b0 >> >> vm_fault() at data_abort+0xe0 >> pc = 0xffff0000005b9464 lr = 0xffff00000061ad94 >> sp = 0xffff0000402380c0 fp = 0xffff000040238170 >> >> data_abort() at handle_el1h_sync+0x70 >> pc = 0xffff00000061ad94 lr = 0xffff000000607870 >> sp = 0xffff000040238180 fp = 0xffff000040238290 >> >> handle_el1h_sync() at pmap_enter+0x678 >> pc = 0xffff000000607870 lr = 0xffff000000615684 >> sp = 0xffff0000402382a0 fp = 0xffff0000402383b0 >> >> pmap_enter() at vm_fault_hold+0x17c0 >> pc = 0xffff000000615684 lr = 0xffff0000005bac74 >> sp = 0xffff0000402383c0 fp = 0xffff000040238510 >> >> vm_fault_hold() at vm_fault+0x70 >> pc = 0xffff0000005bac74 lr = 0xffff0000005b9464 >> sp = 0xffff000040238520 fp = 0xffff000040238550 >> >> vm_fault() at data_abort+0xe0 >> pc = 0xffff0000005b9464 lr = 0xffff00000061ad94 >> sp = 0xffff000040238560 fp = 0xffff000040238610 >> >> data_abort() at handle_el1h_sync+0x70 >> pc = 0xffff00000061ad94 lr = 0xffff000000607870 >> sp = 0xffff000040238620 fp = 0xffff000040238730 >> >> handle_el1h_sync() at pmap_remove_pages+0x2a8 >> pc = 0xffff000000607870 lr = 0xffff0000006175d4 >> sp = 0xffff000040238740 fp = 0xffff000040238870 >> >> pmap_remove_pages() at vmspace_exit+0xb0 >> pc = 0xffff0000006175d4 lr = 0xffff0000005c020c >> sp = 0xffff000040238880 fp = 0xffff0000402388b0 >> >> vmspace_exit() at exit1+0x604 >> pc = 0xffff0000005c020c lr = 0xffff0000002db5e0 >> sp = 0xffff0000402388c0 fp = 0xffff000040238920 >> >> exit1() at sys_sys_exit+0x10 >> pc = 0xffff0000002db5e0 lr = 0xffff0000002dafd8 >> sp = 0xffff000040238930 fp = 0xffff000040238930 >> >> sys_sys_exit() at do_el0_sync+0xa48 >> pc = 0xffff0000002dafd8 lr = 0xffff00000061b91c >> sp = 0xffff000040238940 fp = 0xffff000040238a70 >> >> do_el0_sync() at handle_el0_sync+0x6c >> pc = 0xffff00000061b91c lr = 0xffff0000006079e8 >> sp = 0xffff000040238a80 fp = 0xffff000040238b90 >> >> handle_el0_sync() at 0x38cc0 >> pc = 0xffff0000006079e8 lr = 0x0000000000038cc0 >> sp = 0xffff000040238ba0 fp = 0x0000ffffffffed00 >> >> panic: sleeping thread >> cpuid = 2 >> time = 1493581440 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self_wrapper+0x28 >> pc = 0xffff000000605cc0 lr = 0xffff0000000869cc >> sp = 0xffff000065dfd320 fp = 0xffff000065dfd530 >> >> db_trace_self_wrapper() at vpanic+0x164 >> pc = 0xffff0000000869cc lr = 0xffff00000031d464 >> sp = 0xffff000065dfd540 fp = 0xffff000065dfd5b0 >> >> vpanic() at panic+0x4c >> pc = 0xffff00000031d464 lr = 0xffff00000031d2fc >> sp = 0xffff000065dfd5c0 fp = 0xffff000065dfd640 >> >> panic() at propagate_priority+0x2d0 >> pc = 0xffff00000031d2fc lr = 0xffff000000374558 >> sp = 0xffff000065dfd650 fp = 0xffff000065dfd690 >> >> propagate_priority() at turnstile_wait+0x340 >> pc = 0xffff000000374558 lr = 0xffff00000037503c >> sp = 0xffff000065dfd6a0 fp = 0xffff000065dfd6e0 >> >> turnstile_wait() at __rw_wlock_hard+0x208 >> pc = 0xffff00000037503c lr = 0xffff000000319138 >> sp = 0xffff000065dfd6f0 fp = 0xffff000065dfd770 >> >> __rw_wlock_hard() at pmap_enter+0xe98 >> pc = 0xffff000000319138 lr = 0xffff000000615ea4 >> sp = 0xffff000065dfd780 fp = 0xffff000065dfd810 >> >> pmap_enter() at vm_fault_hold+0x28c >> pc = 0xffff000000615ea4 lr = 0xffff0000005b9740 >> sp = 0xffff000065dfd820 fp = 0xffff000065dfd970 >> >> vm_fault_hold() at vm_fault+0x70 >> pc = 0xffff0000005b9740 lr = 0xffff0000005b9464 >> sp = 0xffff000065dfd980 fp = 0xffff000065dfd9b0 >> >> vm_fault() at data_abort+0xe0 >> pc = 0xffff0000005b9464 lr = 0xffff00000061ad94 >> sp = 0xffff000065dfd9c0 fp = 0xffff000065dfda70 >> >> data_abort() at handle_el0_sync+0x6c >> pc = 0xffff00000061ad94 lr = 0xffff0000006079e8 >> sp = 0xffff000065dfda80 fp = 0xffff000065dfdb90 >> >> handle_el0_sync() at 0x40040070 >> pc = 0xffff0000006079e8 lr = 0x0000000040040070 >> sp = 0xffff000065dfdba0 fp = 0x0000ffffffffeb00 >> >> KDB: enter: panic >> [ thread pid 709 tid 100086 ] >> Stopped at kdb_enter+0x44: undefined d4200000 >> db> > > Another example failure is: > > Fatal data abort: > x0: 400a9000 > x1: 1000 > x2: 0 > x3: 40 > x4: 3f > x5: fffffd00304e5000 > x6: 2b52 > x7: c > x8: b > x9: fffffd000076d5d0 > x10: 68 > x11: 40000000 > x12: 704c5000 > x13: 42b42003 > x14: 42b42003 > x15: 40000000 > x16: c > x17: ffffffffffffffff > x18: ffff000065dd5310 > x19: 800000000000000 > x20: 1 > x21: fffffd0002b43000 > x22: 12000004556478b > x23: f000000000000000 > x24: fffffd0002b41bc8 > x25: 40 > x26: fffffd0002b42548 > x27: 7b > x28: 3 > x29: ffff000065dd53c0 > sp: ffff000065dd5310 > lr: ffff0000006175d8 > elr: ffff00000060589c > spsr: 60000345 > far: 400a9000 > esr: 96000147 > [ thread pid 715 tid 100078 ] > Stopped at arm64_dcache_wb_range+0x18: undefined d50b7a20 > db> bt > Tracing pid 715 tid 100078 td 0xfffffd00007849c0 > db_trace_self() at db_stack_trace+0xf0 > pc = 0xffff000000605cc0 lr = 0xffff0000000840e0 > sp = 0xffff000065dd4cb0 fp = 0xffff000065dd4ce0 > > db_stack_trace() at db_command+0x23c > pc = 0xffff0000000840e0 lr = 0xffff000000083d58 > sp = 0xffff000065dd4cf0 fp = 0xffff000065dd4dd0 > > db_command() at db_command_loop+0x60 > pc = 0xffff000000083d58 lr = 0xffff000000083b00 > sp = 0xffff000065dd4de0 fp = 0xffff000065dd4e00 > > db_command_loop() at db_trap+0xf4 > pc = 0xffff000000083b00 lr = 0xffff000000086b34 > sp = 0xffff000065dd4e10 fp = 0xffff000065dd5030 > > db_trap() at kdb_trap+0x180 > pc = 0xffff000000086b34 lr = 0xffff00000035f650 > sp = 0xffff000065dd5040 fp = 0xffff000065dd50a0 > > kdb_trap() at data_abort+0x1a0 > pc = 0xffff00000035f650 lr = 0xffff00000061ae54 > sp = 0xffff000065dd50b0 fp = 0xffff000065dd5160 > > data_abort() at handle_el1h_sync+0x70 > pc = 0xffff00000061ae54 lr = 0xffff000000607870 > sp = 0xffff000065dd5170 fp = 0xffff000065dd5280 > > handle_el1h_sync() at pmap_remove_pages+0x2a8 > pc = 0xffff000000607870 lr = 0xffff0000006175d4 > sp = 0xffff000065dd5290 fp = 0xffff000065dd53c0 > > pmap_remove_pages() at exec_new_vmspace+0x1a4 > pc = 0xffff0000006175d4 lr = 0xffff0000002d9da0 > sp = 0xffff000065dd53d0 fp = 0xffff000065dd5430 > > exec_new_vmspace() at exec_elf64_imgact+0xa70 > pc = 0xffff0000002d9da0 lr = 0xffff0000002b7c14 > sp = 0xffff000065dd5440 fp = 0xffff000065dd5550 > > exec_elf64_imgact() at kern_execve+0x664 > pc = 0xffff0000002b7c14 lr = 0xffff0000002d8730 > sp = 0xffff000065dd5560 fp = 0xffff000065dd58b0 > > kern_execve() at sys_execve+0x54 > pc = 0xffff0000002d8730 lr = 0xffff0000002d7d90 > sp = 0xffff000065dd58c0 fp = 0xffff000065dd5930 > > sys_execve() at do_el0_sync+0xa48 > pc = 0xffff0000002d7d90 lr = 0xffff00000061b91c > sp = 0xffff000065dd5940 fp = 0xffff000065dd5a70 > > do_el0_sync() at handle_el0_sync+0x6c > pc = 0xffff00000061b91c lr = 0xffff0000006079e8 > sp = 0xffff000065dd5a80 fp = 0xffff000065dd5b90 > > handle_el0_sync() at 0x24a90 > pc = 0xffff0000006079e8 lr = 0x0000000000024a90 > sp = 0xffff000065dd5ba0 fp = 0x0000ffffffffe7d0 > > db> === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue May 2 21:30: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 91C35D5A7BB for ; Tue, 2 May 2017 21:30:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-63.reflexion.net [208.70.210.63]) (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 501AC19F3 for ; Tue, 2 May 2017 21:30:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7475 invoked from network); 2 May 2017 21:33:24 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 May 2017 21:33:24 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 02 May 2017 17:30:07 -0400 (EDT) Received: (qmail 24247 invoked from network); 2 May 2017 21:30:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 May 2017 21:30:06 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 217C4EC8552; Tue, 2 May 2017 14:30:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots but gets some panics] From: Mark Millard In-Reply-To: <9E66D0B3-3682-49DD-A792-95E29F9DC55C@dsl-only.net> Date: Tue, 2 May 2017 14:30:05 -0700 Cc: "O. Hartmann" , Tom Vijlbrief Content-Transfer-Encoding: quoted-printable Message-Id: <934E8CA3-A100-47F8-B6F7-F49C83AA8EF0@dsl-only.net> References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> <9E66D0B3-3682-49DD-A792-95E29F9DC55C@dsl-only.net> To: freebsd-arm , FreeBSD Current , Andrew Turner , Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 21:30:08 -0000 On 2017-May-2, at 2:22 PM, Mark Millard wrote: > It turns out that the bt's from the example panics are > repeatable for the pc and lr sequence involved (but not > the specific sp's and fp's involved). I report this in > case it suggests anything. I'll note that the build had > a production style kernel for a build of -r317015 . >=20 > The first type of panic actually a back to back > sequence of two bt's, this is the sleeping-thread type > pf example. The second type is just one bt by itself. >=20 > There is one variable lr in the bt for the sleeping-thread > type of example (the first type of panic of the two shown > later, the one with back-to-back bt's): >=20 > 131,133c131,133 > < handle_el0_sync() at 0x40040070 > < pc =3D 0xffff0000006079e8 lr =3D 0x0000000040040070 > < sp =3D 0xffff000065dfdba0 fp =3D 0x0000ffffffffeb00 > --- >> handle_el0_sync() at 0x40044490 >> pc =3D 0xffff0000006079e8 lr =3D 0x0000000040044490 >> sp =3D 0xffff000040229ba0 fp =3D 0x0000ffffffffe3d0 >=20 > Otherwise the two bt's in the example match for the pc/lr > sequence. >=20 > I only have the two examples of this type to compare so > far (one diff). >=20 > I have 3 examples of the second type and they had no such > variation. >=20 > One thing in common to all 5 of these examples is the > sequence: >=20 > data_abort() at handle_el1h_sync+0x70 > lr =3D 0xffff000000607870 > handle_el1h_sync() at pmap_remove_pages+0x2a8 > pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 > pmap_remove_pages() >=20 > being involved in each example. >=20 >=20 > I'm not saying that I can cause any panics at will, but > when either of the two types happen the bt is (mostly) > stable for the pc and lr sequence and that short > sequence above is involved. >=20 > I have seen one other type of panic but I did not manage > to record a bt for it yet. It involved the instruction > cache instead of arm64_dcache_wb_range . >=20 > I quote the prior reported example bt's below. >=20 > On 2017-May-2, at 5:24 AM, Mark Millard = wrote: >=20 >> On 2017-May-2, at 3:37 AM, Mark Millard = wrote: >>=20 >>> On 2017-May-2, at 2:53 AM, Mark Millard = wrote: >>>=20 >>> . . . >>> FYI: >>>=20 >>> I do sometimes get things like: >>>=20 >>>=20 >>> System shutdown time has arrived >>> Apr 30 19:43:15 ODC2FBSD shutdown: power-down by root:=20 >>> Sleeping thread (tid 100093, pid 708) owns a non-sleepable lock >>> KDB: stack backtrace of thread 100093: >>> sched_switch() at mi_switch+0x100 >>> pc =3D 0xffff000000347d44 lr =3D 0xffff000000327358 >>> sp =3D 0xffff000040237e00 fp =3D 0xffff000040237e20 >>>=20 >>> mi_switch() at sleepq_wait+0x3c >>> pc =3D 0xffff000000327358 lr =3D 0xffff00000036c174 >>> sp =3D 0xffff000040237e30 fp =3D 0xffff000040237e50 >>>=20 >>> sleepq_wait() at _sleep+0x29c >>> pc =3D 0xffff00000036c174 lr =3D 0xffff000000326c7c >>> sp =3D 0xffff000040237e60 fp =3D 0xffff000040237ee0 >>>=20 >>> _sleep() at vm_page_sleep_if_busy+0xb0 >>> pc =3D 0xffff000000326c7c lr =3D 0xffff0000005cfcf4 >>> sp =3D 0xffff000040237ef0 fp =3D 0xffff000040237f10 >>>=20 >>> vm_page_sleep_if_busy() at vm_fault_hold+0xcc8 >>> pc =3D 0xffff0000005cfcf4 lr =3D 0xffff0000005ba17c >>> sp =3D 0xffff000040237f20 fp =3D 0xffff000040238070 >>>=20 >>> vm_fault_hold() at vm_fault+0x70 >>> pc =3D 0xffff0000005ba17c lr =3D 0xffff0000005b9464 >>> sp =3D 0xffff000040238080 fp =3D 0xffff0000402380b0 >>>=20 >>> vm_fault() at data_abort+0xe0 >>> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >>> sp =3D 0xffff0000402380c0 fp =3D 0xffff000040238170 >>>=20 >>> data_abort() at handle_el1h_sync+0x70 >>> pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 >>> sp =3D 0xffff000040238180 fp =3D 0xffff000040238290 >>>=20 >>> handle_el1h_sync() at pmap_enter+0x678 >>> pc =3D 0xffff000000607870 lr =3D 0xffff000000615684 >>> sp =3D 0xffff0000402382a0 fp =3D 0xffff0000402383b0 >>>=20 >>> pmap_enter() at vm_fault_hold+0x17c0 >>> pc =3D 0xffff000000615684 lr =3D 0xffff0000005bac74 >>> sp =3D 0xffff0000402383c0 fp =3D 0xffff000040238510 >>>=20 >>> vm_fault_hold() at vm_fault+0x70 >>> pc =3D 0xffff0000005bac74 lr =3D 0xffff0000005b9464 >>> sp =3D 0xffff000040238520 fp =3D 0xffff000040238550 >>>=20 >>> vm_fault() at data_abort+0xe0 >>> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >>> sp =3D 0xffff000040238560 fp =3D 0xffff000040238610 >>>=20 >>> data_abort() at handle_el1h_sync+0x70 >>> pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 >>> sp =3D 0xffff000040238620 fp =3D 0xffff000040238730 >>>=20 >>> handle_el1h_sync() at pmap_remove_pages+0x2a8 >>> pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 >>> sp =3D 0xffff000040238740 fp =3D 0xffff000040238870 >>>=20 >>> pmap_remove_pages() at vmspace_exit+0xb0 >>> pc =3D 0xffff0000006175d4 lr =3D 0xffff0000005c020c >>> sp =3D 0xffff000040238880 fp =3D 0xffff0000402388b0 >>>=20 >>> vmspace_exit() at exit1+0x604 >>> pc =3D 0xffff0000005c020c lr =3D 0xffff0000002db5e0 >>> sp =3D 0xffff0000402388c0 fp =3D 0xffff000040238920 >>>=20 >>> exit1() at sys_sys_exit+0x10 >>> pc =3D 0xffff0000002db5e0 lr =3D 0xffff0000002dafd8 >>> sp =3D 0xffff000040238930 fp =3D 0xffff000040238930 >>>=20 >>> sys_sys_exit() at do_el0_sync+0xa48 >>> pc =3D 0xffff0000002dafd8 lr =3D 0xffff00000061b91c >>> sp =3D 0xffff000040238940 fp =3D 0xffff000040238a70 >>>=20 >>> do_el0_sync() at handle_el0_sync+0x6c >>> pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 >>> sp =3D 0xffff000040238a80 fp =3D 0xffff000040238b90 >>>=20 >>> handle_el0_sync() at 0x38cc0 >>> pc =3D 0xffff0000006079e8 lr =3D 0x0000000000038cc0 >>> sp =3D 0xffff000040238ba0 fp =3D 0x0000ffffffffed00 >>>=20 >>> panic: sleeping thread >>> cpuid =3D 2 >>> time =3D 1493581440 >>> KDB: stack backtrace: >>> db_trace_self() at db_trace_self_wrapper+0x28 >>> pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc >>> sp =3D 0xffff000065dfd320 fp =3D 0xffff000065dfd530 >>>=20 >>> db_trace_self_wrapper() at vpanic+0x164 >>> pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 >>> sp =3D 0xffff000065dfd540 fp =3D 0xffff000065dfd5b0 >>>=20 >>> vpanic() at panic+0x4c >>> pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc >>> sp =3D 0xffff000065dfd5c0 fp =3D 0xffff000065dfd640 >>>=20 >>> panic() at propagate_priority+0x2d0 >>> pc =3D 0xffff00000031d2fc lr =3D 0xffff000000374558 >>> sp =3D 0xffff000065dfd650 fp =3D 0xffff000065dfd690 >>>=20 >>> propagate_priority() at turnstile_wait+0x340 >>> pc =3D 0xffff000000374558 lr =3D 0xffff00000037503c >>> sp =3D 0xffff000065dfd6a0 fp =3D 0xffff000065dfd6e0 >>>=20 >>> turnstile_wait() at __rw_wlock_hard+0x208 >>> pc =3D 0xffff00000037503c lr =3D 0xffff000000319138 >>> sp =3D 0xffff000065dfd6f0 fp =3D 0xffff000065dfd770 >>>=20 >>> __rw_wlock_hard() at pmap_enter+0xe98 >>> pc =3D 0xffff000000319138 lr =3D 0xffff000000615ea4 >>> sp =3D 0xffff000065dfd780 fp =3D 0xffff000065dfd810 >>>=20 >>> pmap_enter() at vm_fault_hold+0x28c >>> pc =3D 0xffff000000615ea4 lr =3D 0xffff0000005b9740 >>> sp =3D 0xffff000065dfd820 fp =3D 0xffff000065dfd970 >>>=20 >>> vm_fault_hold() at vm_fault+0x70 >>> pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 >>> sp =3D 0xffff000065dfd980 fp =3D 0xffff000065dfd9b0 >>>=20 >>> vm_fault() at data_abort+0xe0 >>> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >>> sp =3D 0xffff000065dfd9c0 fp =3D 0xffff000065dfda70 >>>=20 >>> data_abort() at handle_el0_sync+0x6c >>> pc =3D 0xffff00000061ad94 lr =3D 0xffff0000006079e8 >>> sp =3D 0xffff000065dfda80 fp =3D 0xffff000065dfdb90 >>>=20 >>> handle_el0_sync() at 0x40040070 >>> pc =3D 0xffff0000006079e8 lr =3D 0x0000000040040070 >>> sp =3D 0xffff000065dfdba0 fp =3D 0x0000ffffffffeb00 >>>=20 >>> KDB: enter: panic >>> [ thread pid 709 tid 100086 ] >>> Stopped at kdb_enter+0x44: undefined d4200000 >>> db> >>=20 >> Another example failure is: >>=20 >> Fatal data abort: >> x0: 400a9000 >> x1: 1000 >> x2: 0 >> x3: 40 >> x4: 3f >> x5: fffffd00304e5000 >> x6: 2b52 >> x7: c >> x8: b >> x9: fffffd000076d5d0 >> x10: 68 >> x11: 40000000 >> x12: 704c5000 >> x13: 42b42003 >> x14: 42b42003 >> x15: 40000000 >> x16: c >> x17: ffffffffffffffff >> x18: ffff000065dd5310 >> x19: 800000000000000 >> x20: 1 >> x21: fffffd0002b43000 >> x22: 12000004556478b >> x23: f000000000000000 >> x24: fffffd0002b41bc8 >> x25: 40 >> x26: fffffd0002b42548 >> x27: 7b >> x28: 3 >> x29: ffff000065dd53c0 >> sp: ffff000065dd5310 >> lr: ffff0000006175d8 >> elr: ffff00000060589c >> spsr: 60000345 >> far: 400a9000 >> esr: 96000147 >> [ thread pid 715 tid 100078 ] >> Stopped at arm64_dcache_wb_range+0x18: undefined = d50b7a20 >> db> bt >> Tracing pid 715 tid 100078 td 0xfffffd00007849c0 >> db_trace_self() at db_stack_trace+0xf0 >> pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000840e0 >> sp =3D 0xffff000065dd4cb0 fp =3D 0xffff000065dd4ce0 >>=20 >> db_stack_trace() at db_command+0x23c >> pc =3D 0xffff0000000840e0 lr =3D 0xffff000000083d58 >> sp =3D 0xffff000065dd4cf0 fp =3D 0xffff000065dd4dd0 >>=20 >> db_command() at db_command_loop+0x60 >> pc =3D 0xffff000000083d58 lr =3D 0xffff000000083b00 >> sp =3D 0xffff000065dd4de0 fp =3D 0xffff000065dd4e00 >>=20 >> db_command_loop() at db_trap+0xf4 >> pc =3D 0xffff000000083b00 lr =3D 0xffff000000086b34 >> sp =3D 0xffff000065dd4e10 fp =3D 0xffff000065dd5030 >>=20 >> db_trap() at kdb_trap+0x180 >> pc =3D 0xffff000000086b34 lr =3D 0xffff00000035f650 >> sp =3D 0xffff000065dd5040 fp =3D 0xffff000065dd50a0 >>=20 >> kdb_trap() at data_abort+0x1a0 >> pc =3D 0xffff00000035f650 lr =3D 0xffff00000061ae54 >> sp =3D 0xffff000065dd50b0 fp =3D 0xffff000065dd5160 >>=20 >> data_abort() at handle_el1h_sync+0x70 >> pc =3D 0xffff00000061ae54 lr =3D 0xffff000000607870 >> sp =3D 0xffff000065dd5170 fp =3D 0xffff000065dd5280 >>=20 >> handle_el1h_sync() at pmap_remove_pages+0x2a8 >> pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 >> sp =3D 0xffff000065dd5290 fp =3D 0xffff000065dd53c0 >>=20 >> pmap_remove_pages() at exec_new_vmspace+0x1a4 >> pc =3D 0xffff0000006175d4 lr =3D 0xffff0000002d9da0 >> sp =3D 0xffff000065dd53d0 fp =3D 0xffff000065dd5430 >>=20 >> exec_new_vmspace() at exec_elf64_imgact+0xa70 >> pc =3D 0xffff0000002d9da0 lr =3D 0xffff0000002b7c14 >> sp =3D 0xffff000065dd5440 fp =3D 0xffff000065dd5550 >>=20 >> exec_elf64_imgact() at kern_execve+0x664 >> pc =3D 0xffff0000002b7c14 lr =3D 0xffff0000002d8730 >> sp =3D 0xffff000065dd5560 fp =3D 0xffff000065dd58b0 >>=20 >> kern_execve() at sys_execve+0x54 >> pc =3D 0xffff0000002d8730 lr =3D 0xffff0000002d7d90 >> sp =3D 0xffff000065dd58c0 fp =3D 0xffff000065dd5930 >>=20 >> sys_execve() at do_el0_sync+0xa48 >> pc =3D 0xffff0000002d7d90 lr =3D 0xffff00000061b91c >> sp =3D 0xffff000065dd5940 fp =3D 0xffff000065dd5a70 >>=20 >> do_el0_sync() at handle_el0_sync+0x6c >> pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 >> sp =3D 0xffff000065dd5a80 fp =3D 0xffff000065dd5b90 >>=20 >> handle_el0_sync() at 0x24a90 >> pc =3D 0xffff0000006079e8 lr =3D 0x0000000000024a90 >> sp =3D 0xffff000065dd5ba0 fp =3D 0x0000ffffffffe7d0 >>=20 >> db>=20 Because Konstanin B. was not Cc'd/To'd previously I should have included the following background information about how this was run on a Odroid-C2 under UbuntuMate: qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -machine virt \ -bios QEMU_EFI.fd -nographic \ -drive = format=3Draw,if=3Dnone,file=3DFreeBSD-12.0-CURRENT-arm64-aarch64.raw,id=3D= hd0 \ -device virtio-blk-device,drive=3Dhd0 \ -device virtio-net-device,netdev=3Dnet0 \ -netdev user,id=3Dnet0 \ -smp cpus=3D4 based on: = https://releases.linaro.org/components/kernel/uefi-linaro/16.02/release/qe= mu64/QEMU_EFI.fd and my build of head -r317015 turned into a .raw file. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue May 2 21:59: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 98E9BD5B7E9 for ; Tue, 2 May 2017 21:59:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-63.reflexion.net [208.70.210.63]) (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 5AFBC182 for ; Tue, 2 May 2017 21:59:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2518 invoked from network); 2 May 2017 21:59:56 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 2 May 2017 21:59:56 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 02 May 2017 17:59:56 -0400 (EDT) Received: (qmail 24629 invoked from network); 2 May 2017 21:59:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 May 2017 21:59:56 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CA13CEC913D; Tue, 2 May 2017 14:59:55 -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: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots but gets some panics] Date: Tue, 2 May 2017 14:59:55 -0700 References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> <9E66D0B3-3682-49DD-A792-95E29F9DC55C@dsl-only.net> <934E8CA3-A100-47F8-B6F7-F49C83AA8EF0@dsl-only.net> To: Andrew Turner , Konstantin Belousov , FreeBSD Current , freebsd-arm In-Reply-To: <934E8CA3-A100-47F8-B6F7-F49C83AA8EF0@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: Tue, 02 May 2017 21:59:58 -0000 On 2017-May-2, at 2:30 PM, Mark Millard wrote: > On 2017-May-2, at 2:22 PM, Mark Millard = wrote: >=20 >> It turns out that the bt's from the example panics are >> repeatable for the pc and lr sequence involved (but not >> the specific sp's and fp's involved). I report this in >> case it suggests anything. I'll note that the build had >> a production style kernel for a build of -r317015 . >>=20 >> The first type of panic actually a back to back >> sequence of two bt's, this is the sleeping-thread type >> pf example. The second type is just one bt by itself. >>=20 >> There is one variable lr in the bt for the sleeping-thread >> type of example (the first type of panic of the two shown >> later, the one with back-to-back bt's): >>=20 >> 131,133c131,133 >> < handle_el0_sync() at 0x40040070 >> < pc =3D 0xffff0000006079e8 lr =3D 0x0000000040040070 >> < sp =3D 0xffff000065dfdba0 fp =3D 0x0000ffffffffeb00 >> --- >>> handle_el0_sync() at 0x40044490 >>> pc =3D 0xffff0000006079e8 lr =3D 0x0000000040044490 >>> sp =3D 0xffff000040229ba0 fp =3D 0x0000ffffffffe3d0 >>=20 >> Otherwise the two bt's in the example match for the pc/lr >> sequence. >>=20 >> I only have the two examples of this type to compare so >> far (one diff). >>=20 >> I have 3 examples of the second type and they had no such >> variation. >>=20 >> One thing in common to all 5 of these examples is the >> sequence: >>=20 >> data_abort() at handle_el1h_sync+0x70 >> lr =3D 0xffff000000607870 >> handle_el1h_sync() at pmap_remove_pages+0x2a8 >> pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 >> pmap_remove_pages() >>=20 >> being involved in each example. >>=20 >>=20 >> I'm not saying that I can cause any panics at will, but >> when either of the two types happen the bt is (mostly) >> stable for the pc and lr sequence and that short >> sequence above is involved. >>=20 >> I have seen one other type of panic but I did not manage >> to record a bt for it yet. It involved the instruction >> cache instead of arm64_dcache_wb_range . >>=20 >> I quote the prior reported example bt's below. >>=20 >> On 2017-May-2, at 5:24 AM, Mark Millard = wrote: >>=20 >>> On 2017-May-2, at 3:37 AM, Mark Millard = wrote: >>>=20 >>>> On 2017-May-2, at 2:53 AM, Mark Millard = wrote: >>>>=20 >>>> . . . >>>> FYI: >>>>=20 >>>> I do sometimes get things like: >>>>=20 >>>>=20 >>>> System shutdown time has arrived >>>> Apr 30 19:43:15 ODC2FBSD shutdown: power-down by root:=20 >>>> Sleeping thread (tid 100093, pid 708) owns a non-sleepable lock >>>> KDB: stack backtrace of thread 100093: >>>> sched_switch() at mi_switch+0x100 >>>> pc =3D 0xffff000000347d44 lr =3D 0xffff000000327358 >>>> sp =3D 0xffff000040237e00 fp =3D 0xffff000040237e20 >>>>=20 >>>> mi_switch() at sleepq_wait+0x3c >>>> pc =3D 0xffff000000327358 lr =3D 0xffff00000036c174 >>>> sp =3D 0xffff000040237e30 fp =3D 0xffff000040237e50 >>>>=20 >>>> sleepq_wait() at _sleep+0x29c >>>> pc =3D 0xffff00000036c174 lr =3D 0xffff000000326c7c >>>> sp =3D 0xffff000040237e60 fp =3D 0xffff000040237ee0 >>>>=20 >>>> _sleep() at vm_page_sleep_if_busy+0xb0 >>>> pc =3D 0xffff000000326c7c lr =3D 0xffff0000005cfcf4 >>>> sp =3D 0xffff000040237ef0 fp =3D 0xffff000040237f10 >>>>=20 >>>> vm_page_sleep_if_busy() at vm_fault_hold+0xcc8 >>>> pc =3D 0xffff0000005cfcf4 lr =3D 0xffff0000005ba17c >>>> sp =3D 0xffff000040237f20 fp =3D 0xffff000040238070 >>>>=20 >>>> vm_fault_hold() at vm_fault+0x70 >>>> pc =3D 0xffff0000005ba17c lr =3D 0xffff0000005b9464 >>>> sp =3D 0xffff000040238080 fp =3D 0xffff0000402380b0 >>>>=20 >>>> vm_fault() at data_abort+0xe0 >>>> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >>>> sp =3D 0xffff0000402380c0 fp =3D 0xffff000040238170 >>>>=20 >>>> data_abort() at handle_el1h_sync+0x70 >>>> pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 >>>> sp =3D 0xffff000040238180 fp =3D 0xffff000040238290 >>>>=20 >>>> handle_el1h_sync() at pmap_enter+0x678 >>>> pc =3D 0xffff000000607870 lr =3D 0xffff000000615684 >>>> sp =3D 0xffff0000402382a0 fp =3D 0xffff0000402383b0 >>>>=20 >>>> pmap_enter() at vm_fault_hold+0x17c0 >>>> pc =3D 0xffff000000615684 lr =3D 0xffff0000005bac74 >>>> sp =3D 0xffff0000402383c0 fp =3D 0xffff000040238510 >>>>=20 >>>> vm_fault_hold() at vm_fault+0x70 >>>> pc =3D 0xffff0000005bac74 lr =3D 0xffff0000005b9464 >>>> sp =3D 0xffff000040238520 fp =3D 0xffff000040238550 >>>>=20 >>>> vm_fault() at data_abort+0xe0 >>>> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >>>> sp =3D 0xffff000040238560 fp =3D 0xffff000040238610 >>>>=20 >>>> data_abort() at handle_el1h_sync+0x70 >>>> pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 >>>> sp =3D 0xffff000040238620 fp =3D 0xffff000040238730 >>>>=20 >>>> handle_el1h_sync() at pmap_remove_pages+0x2a8 >>>> pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 >>>> sp =3D 0xffff000040238740 fp =3D 0xffff000040238870 >>>>=20 >>>> pmap_remove_pages() at vmspace_exit+0xb0 >>>> pc =3D 0xffff0000006175d4 lr =3D 0xffff0000005c020c >>>> sp =3D 0xffff000040238880 fp =3D 0xffff0000402388b0 >>>>=20 >>>> vmspace_exit() at exit1+0x604 >>>> pc =3D 0xffff0000005c020c lr =3D 0xffff0000002db5e0 >>>> sp =3D 0xffff0000402388c0 fp =3D 0xffff000040238920 >>>>=20 >>>> exit1() at sys_sys_exit+0x10 >>>> pc =3D 0xffff0000002db5e0 lr =3D 0xffff0000002dafd8 >>>> sp =3D 0xffff000040238930 fp =3D 0xffff000040238930 >>>>=20 >>>> sys_sys_exit() at do_el0_sync+0xa48 >>>> pc =3D 0xffff0000002dafd8 lr =3D 0xffff00000061b91c >>>> sp =3D 0xffff000040238940 fp =3D 0xffff000040238a70 >>>>=20 >>>> do_el0_sync() at handle_el0_sync+0x6c >>>> pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 >>>> sp =3D 0xffff000040238a80 fp =3D 0xffff000040238b90 >>>>=20 >>>> handle_el0_sync() at 0x38cc0 >>>> pc =3D 0xffff0000006079e8 lr =3D 0x0000000000038cc0 >>>> sp =3D 0xffff000040238ba0 fp =3D 0x0000ffffffffed00 >>>>=20 >>>> panic: sleeping thread >>>> cpuid =3D 2 >>>> time =3D 1493581440 >>>> KDB: stack backtrace: >>>> db_trace_self() at db_trace_self_wrapper+0x28 >>>> pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc >>>> sp =3D 0xffff000065dfd320 fp =3D 0xffff000065dfd530 >>>>=20 >>>> db_trace_self_wrapper() at vpanic+0x164 >>>> pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 >>>> sp =3D 0xffff000065dfd540 fp =3D 0xffff000065dfd5b0 >>>>=20 >>>> vpanic() at panic+0x4c >>>> pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc >>>> sp =3D 0xffff000065dfd5c0 fp =3D 0xffff000065dfd640 >>>>=20 >>>> panic() at propagate_priority+0x2d0 >>>> pc =3D 0xffff00000031d2fc lr =3D 0xffff000000374558 >>>> sp =3D 0xffff000065dfd650 fp =3D 0xffff000065dfd690 >>>>=20 >>>> propagate_priority() at turnstile_wait+0x340 >>>> pc =3D 0xffff000000374558 lr =3D 0xffff00000037503c >>>> sp =3D 0xffff000065dfd6a0 fp =3D 0xffff000065dfd6e0 >>>>=20 >>>> turnstile_wait() at __rw_wlock_hard+0x208 >>>> pc =3D 0xffff00000037503c lr =3D 0xffff000000319138 >>>> sp =3D 0xffff000065dfd6f0 fp =3D 0xffff000065dfd770 >>>>=20 >>>> __rw_wlock_hard() at pmap_enter+0xe98 >>>> pc =3D 0xffff000000319138 lr =3D 0xffff000000615ea4 >>>> sp =3D 0xffff000065dfd780 fp =3D 0xffff000065dfd810 >>>>=20 >>>> pmap_enter() at vm_fault_hold+0x28c >>>> pc =3D 0xffff000000615ea4 lr =3D 0xffff0000005b9740 >>>> sp =3D 0xffff000065dfd820 fp =3D 0xffff000065dfd970 >>>>=20 >>>> vm_fault_hold() at vm_fault+0x70 >>>> pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 >>>> sp =3D 0xffff000065dfd980 fp =3D 0xffff000065dfd9b0 >>>>=20 >>>> vm_fault() at data_abort+0xe0 >>>> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >>>> sp =3D 0xffff000065dfd9c0 fp =3D 0xffff000065dfda70 >>>>=20 >>>> data_abort() at handle_el0_sync+0x6c >>>> pc =3D 0xffff00000061ad94 lr =3D 0xffff0000006079e8 >>>> sp =3D 0xffff000065dfda80 fp =3D 0xffff000065dfdb90 >>>>=20 >>>> handle_el0_sync() at 0x40040070 >>>> pc =3D 0xffff0000006079e8 lr =3D 0x0000000040040070 >>>> sp =3D 0xffff000065dfdba0 fp =3D 0x0000ffffffffeb00 >>>>=20 >>>> KDB: enter: panic >>>> [ thread pid 709 tid 100086 ] >>>> Stopped at kdb_enter+0x44: undefined d4200000 >>>> db> >>>=20 >>> Another example failure is: >>>=20 >>> Fatal data abort: >>> x0: 400a9000 >>> x1: 1000 >>> x2: 0 >>> x3: 40 >>> x4: 3f >>> x5: fffffd00304e5000 >>> x6: 2b52 >>> x7: c >>> x8: b >>> x9: fffffd000076d5d0 >>> x10: 68 >>> x11: 40000000 >>> x12: 704c5000 >>> x13: 42b42003 >>> x14: 42b42003 >>> x15: 40000000 >>> x16: c >>> x17: ffffffffffffffff >>> x18: ffff000065dd5310 >>> x19: 800000000000000 >>> x20: 1 >>> x21: fffffd0002b43000 >>> x22: 12000004556478b >>> x23: f000000000000000 >>> x24: fffffd0002b41bc8 >>> x25: 40 >>> x26: fffffd0002b42548 >>> x27: 7b >>> x28: 3 >>> x29: ffff000065dd53c0 >>> sp: ffff000065dd5310 >>> lr: ffff0000006175d8 >>> elr: ffff00000060589c >>> spsr: 60000345 >>> far: 400a9000 >>> esr: 96000147 >>> [ thread pid 715 tid 100078 ] >>> Stopped at arm64_dcache_wb_range+0x18: undefined = d50b7a20 >>> db> bt >>> Tracing pid 715 tid 100078 td 0xfffffd00007849c0 >>> db_trace_self() at db_stack_trace+0xf0 >>> pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000840e0 >>> sp =3D 0xffff000065dd4cb0 fp =3D 0xffff000065dd4ce0 >>>=20 >>> db_stack_trace() at db_command+0x23c >>> pc =3D 0xffff0000000840e0 lr =3D 0xffff000000083d58 >>> sp =3D 0xffff000065dd4cf0 fp =3D 0xffff000065dd4dd0 >>>=20 >>> db_command() at db_command_loop+0x60 >>> pc =3D 0xffff000000083d58 lr =3D 0xffff000000083b00 >>> sp =3D 0xffff000065dd4de0 fp =3D 0xffff000065dd4e00 >>>=20 >>> db_command_loop() at db_trap+0xf4 >>> pc =3D 0xffff000000083b00 lr =3D 0xffff000000086b34 >>> sp =3D 0xffff000065dd4e10 fp =3D 0xffff000065dd5030 >>>=20 >>> db_trap() at kdb_trap+0x180 >>> pc =3D 0xffff000000086b34 lr =3D 0xffff00000035f650 >>> sp =3D 0xffff000065dd5040 fp =3D 0xffff000065dd50a0 >>>=20 >>> kdb_trap() at data_abort+0x1a0 >>> pc =3D 0xffff00000035f650 lr =3D 0xffff00000061ae54 >>> sp =3D 0xffff000065dd50b0 fp =3D 0xffff000065dd5160 >>>=20 >>> data_abort() at handle_el1h_sync+0x70 >>> pc =3D 0xffff00000061ae54 lr =3D 0xffff000000607870 >>> sp =3D 0xffff000065dd5170 fp =3D 0xffff000065dd5280 >>>=20 >>> handle_el1h_sync() at pmap_remove_pages+0x2a8 >>> pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 >>> sp =3D 0xffff000065dd5290 fp =3D 0xffff000065dd53c0 >>>=20 >>> pmap_remove_pages() at exec_new_vmspace+0x1a4 >>> pc =3D 0xffff0000006175d4 lr =3D 0xffff0000002d9da0 >>> sp =3D 0xffff000065dd53d0 fp =3D 0xffff000065dd5430 >>>=20 >>> exec_new_vmspace() at exec_elf64_imgact+0xa70 >>> pc =3D 0xffff0000002d9da0 lr =3D 0xffff0000002b7c14 >>> sp =3D 0xffff000065dd5440 fp =3D 0xffff000065dd5550 >>>=20 >>> exec_elf64_imgact() at kern_execve+0x664 >>> pc =3D 0xffff0000002b7c14 lr =3D 0xffff0000002d8730 >>> sp =3D 0xffff000065dd5560 fp =3D 0xffff000065dd58b0 >>>=20 >>> kern_execve() at sys_execve+0x54 >>> pc =3D 0xffff0000002d8730 lr =3D 0xffff0000002d7d90 >>> sp =3D 0xffff000065dd58c0 fp =3D 0xffff000065dd5930 >>>=20 >>> sys_execve() at do_el0_sync+0xa48 >>> pc =3D 0xffff0000002d7d90 lr =3D 0xffff00000061b91c >>> sp =3D 0xffff000065dd5940 fp =3D 0xffff000065dd5a70 >>>=20 >>> do_el0_sync() at handle_el0_sync+0x6c >>> pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 >>> sp =3D 0xffff000065dd5a80 fp =3D 0xffff000065dd5b90 >>>=20 >>> handle_el0_sync() at 0x24a90 >>> pc =3D 0xffff0000006079e8 lr =3D 0x0000000000024a90 >>> sp =3D 0xffff000065dd5ba0 fp =3D 0x0000ffffffffe7d0 >>>=20 >>> db>=20 >=20 > Because Konstanin B. was not Cc'd/To'd previously > I should have included the following background > information about how this was run on a > Odroid-C2 under UbuntuMate: >=20 > qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -machine virt \ > -bios QEMU_EFI.fd -nographic \ > -drive = format=3Draw,if=3Dnone,file=3DFreeBSD-12.0-CURRENT-arm64-aarch64.raw,id=3D= hd0 \ > -device virtio-blk-device,drive=3Dhd0 \ > -device virtio-net-device,netdev=3Dnet0 \ > -netdev user,id=3Dnet0 \ > -smp cpus=3D4 >=20 > based on: >=20 > = https://releases.linaro.org/components/kernel/uefi-linaro/16.02/release/qe= mu64/QEMU_EFI.fd >=20 > and my build of head -r317015 turned into a .raw file. The code around handle_el1h_sync+0x70 : ffff000000607804 sub sp, sp, #0x80 ffff000000607808 sub sp, sp, #0x120 ffff00000060780c stp x29, x30, [sp,#272] ffff000000607810 stp x28, x29, [sp,#256] ffff000000607814 stp x26, x27, [sp,#240] ffff000000607818 stp x24, x25, [sp,#224] ffff00000060781c stp x22, x23, [sp,#208] ffff000000607820 stp x20, x21, [sp,#192] ffff000000607824 stp x18, x19, [sp,#176] ffff000000607828 stp x16, x17, [sp,#160] ffff00000060782c stp x14, x15, [sp,#144] ffff000000607830 stp x12, x13, [sp,#128] ffff000000607834 stp x10, x11, [sp,#112] ffff000000607838 stp x8, x9, [sp,#96] ffff00000060783c stp x6, x7, [sp,#80] ffff000000607840 stp x4, x5, [sp,#64] ffff000000607844 stp x2, x3, [sp,#48] ffff000000607848 stp x0, x1, [sp,#32] ffff00000060784c mrs x10, elr_el1 ffff000000607850 mrs x11, spsr_el1 ffff000000607854 mrs x12, esr_el1 ffff000000607858 str x10, [sp,#16] ffff00000060785c stp w11, w12, [sp,#24] ffff000000607860 stp x18, x30, [sp] ffff000000607864 mrs x18, tpidr_el1 ffff000000607868 add x29, sp, #0x110 ffff00000060786c mov x0, sp ffff000000607870 bl ffff00000061aad8 = ffff000000607874 msr daifset, #0x2 ffff000000607878 ldp x18, x30, [sp] ffff00000060787c ldp x10, x11, [sp,#16] ffff000000607880 msr spsr_el1, x11 ffff000000607884 msr elr_el1, x10 ffff000000607888 ldp x0, x1, [sp,#32] ffff00000060788c ldp x2, x3, [sp,#48] ffff000000607890 ldp x4, x5, [sp,#64] ffff000000607894 ldp x6, x7, [sp,#80] ffff000000607898 ldp x8, x9, [sp,#96] ffff00000060789c ldp x10, x11, [sp,#112] ffff0000006078a0 ldp x12, x13, [sp,#128] ffff0000006078a4 ldp x14, x15, [sp,#144] ffff0000006078a8 ldp x16, x17, [sp,#160] ffff0000006078ac ldr x29, [sp,#264] ffff0000006078b0 mov sp, x18 ffff0000006078b4 mrs x18, tpidr_el1 ffff0000006078b8 eret So the bl to do_el1h_sync apparently gets the data_abort. The code around pmap_remove_pages+0x2a8 : ffff000000617570 bl ffff0000005cf83c = ffff000000617574 ldr x9, [sp,#80] ffff000000617578 adrp x8, ffff000000bbd000 = ffff00000061757c add x8, x8, #0x848 ffff000000617580 str x0, [sp,#48] ffff000000617584 cmp x9, x8 ffff000000617588 b.eq ffff0000006175a4 = ffff00000061758c ldr x8, [x18] ffff000000617590 ldr x8, [x8,#8] ffff000000617594 ldr x8, [x8,#512] ffff000000617598 ldr x8, [x8,#224] ffff00000061759c cmp x8, x9 ffff0000006175a0 b.ne ffff0000006175d8 = ffff0000006175a4 and x8, x22, #0x1f ffff0000006175a8 cmp x28, #0x3 ffff0000006175ac b.ne ffff0000006175c4 = ffff0000006175b0 cmp x8, #0xb ffff0000006175b4 b.ne ffff0000006175d8 = ffff0000006175b8 ldr x0, [x24] ffff0000006175bc orr w1, wzr, #0x1000 ffff0000006175c0 b ffff0000006175d4 = ffff0000006175c4 cmp x8, #0x9 ffff0000006175c8 b.ne ffff0000006175d8 = ffff0000006175cc ldr x0, [x24] ffff0000006175d0 orr w1, wzr, #0x200000 ffff0000006175d4 bl ffff000000605884 = ffff0000006175d8 mov x8, xzr ffff0000006175dc orr w1, wzr, #0x8 ffff0000006175e0 mov x0, x26 ffff0000006175e4 ldxr x9, [x26] ffff0000006175e8 stxr w10, x8, [x26] ffff0000006175ec cbnz w10, ffff0000006175e4 = ffff0000006175f0 bl ffff000000605884 = So this happens to involve arm64_dcache_wb_range (that has not started yet). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed May 3 01:53: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 D679ED5B88D for ; Wed, 3 May 2017 01:53:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-62.reflexion.net [208.70.210.62]) (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 982861047 for ; Wed, 3 May 2017 01:53:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11863 invoked from network); 3 May 2017 01:53:33 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 3 May 2017 01:53:33 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 02 May 2017 21:53:33 -0400 (EDT) Received: (qmail 8830 invoked from network); 3 May 2017 01:53:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 May 2017 01:53:33 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 9E834EC7ED9; Tue, 2 May 2017 18:53:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots but gets some panics] From: Mark Millard In-Reply-To: Date: Tue, 2 May 2017 18:53:32 -0700 Cc: FreeBSD Current , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> <9E66D0B3-3682-49DD-A792-95E29F9DC55C@dsl-only.net> <934E8CA3-A100-47F8-B6F7-F49C83AA8EF0@dsl-only.net> To: Andrew Turner , Konstantin Belousov 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, 03 May 2017 01:53:35 -0000 On 2017-May-2, at 2:59 PM, Mark Millard wrote: > The code around handle_el1h_sync+0x70 : >=20 > ffff000000607804 sub sp, sp, #0x80 > ffff000000607808 sub sp, sp, #0x120 > ffff00000060780c stp x29, x30, [sp,#272] > ffff000000607810 stp x28, x29, [sp,#256] > ffff000000607814 stp x26, x27, [sp,#240] > ffff000000607818 stp x24, x25, [sp,#224] > ffff00000060781c stp x22, x23, [sp,#208] > ffff000000607820 stp x20, x21, [sp,#192] > ffff000000607824 stp x18, x19, [sp,#176] > ffff000000607828 stp x16, x17, [sp,#160] > ffff00000060782c stp x14, x15, [sp,#144] > ffff000000607830 stp x12, x13, [sp,#128] > ffff000000607834 stp x10, x11, [sp,#112] > ffff000000607838 stp x8, x9, [sp,#96] > ffff00000060783c stp x6, x7, [sp,#80] > ffff000000607840 stp x4, x5, [sp,#64] > ffff000000607844 stp x2, x3, [sp,#48] > ffff000000607848 stp x0, x1, [sp,#32] > ffff00000060784c mrs x10, elr_el1 > ffff000000607850 mrs x11, spsr_el1 > ffff000000607854 mrs x12, esr_el1 > ffff000000607858 str x10, [sp,#16] > ffff00000060785c stp w11, w12, [sp,#24] > ffff000000607860 stp x18, x30, [sp] > ffff000000607864 mrs x18, tpidr_el1 > ffff000000607868 add x29, sp, #0x110 > ffff00000060786c mov x0, sp > ffff000000607870 bl ffff00000061aad8 = > ffff000000607874 msr daifset, #0x2 > ffff000000607878 ldp x18, x30, [sp] > ffff00000060787c ldp x10, x11, [sp,#16] > ffff000000607880 msr spsr_el1, x11 > ffff000000607884 msr elr_el1, x10 > ffff000000607888 ldp x0, x1, [sp,#32] > ffff00000060788c ldp x2, x3, [sp,#48] > ffff000000607890 ldp x4, x5, [sp,#64] > ffff000000607894 ldp x6, x7, [sp,#80] > ffff000000607898 ldp x8, x9, [sp,#96] > ffff00000060789c ldp x10, x11, [sp,#112] > ffff0000006078a0 ldp x12, x13, [sp,#128] > ffff0000006078a4 ldp x14, x15, [sp,#144] > ffff0000006078a8 ldp x16, x17, [sp,#160] > ffff0000006078ac ldr x29, [sp,#264] > ffff0000006078b0 mov sp, x18 > ffff0000006078b4 mrs x18, tpidr_el1 > ffff0000006078b8 eret >=20 > So the bl to do_el1h_sync apparently gets the data_abort. It turns out that in the first type of example there is also a: data_abort() at handle_el1h_sync+0x70 pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 sp =3D 0xffff000040238180 fp =3D 0xffff000040238290 handle_el1h_sync() at pmap_enter+0x678 pc =3D 0xffff000000607870 lr =3D 0xffff000000615684 sp =3D 0xffff0000402382a0 fp =3D 0xffff0000402383b0 in what I showed. And around pmap_enter+0x678 happens to be: ffff00000061566c b ffff000000615688 = ffff000000615670 and x8, x28, #0x1f ffff000000615674 cmp x8, #0xb ffff000000615678 b.ne ffff000000615688 = ffff00000061567c ldr x0, [sp,#32] ffff000000615680 orr w1, wzr, #0x1000 ffff000000615684 bl ffff000000605884 = ffff000000615688 ldrb w8, [x22,#93] ffff00000061568c tbnz w8, #2, ffff0000006157a4 = ffff000000615690 add x1, sp, #0x38 ffff000000615694 mov x0, x19 ffff000000615698 mov x24, x23 ffff00000061569c orr x23, x23, #0x100000000000000 ffff0000006156a0 bl ffff000000615f44 So again handle_el1h_sync happens at a bl to arm64_dcache_wb_range and ends up with a data_abort at handle_el1h_sync+0x70 . The context is pmap_enter instead of pmap_remove_pages. But an example of a pmap_remove_pages+0x2a8 context for handle_el1h_sync is also in the call chain for the first type of example that I originally showed. > The code around pmap_remove_pages+0x2a8 : >=20 > ffff000000617570 bl ffff0000005cf83c = > ffff000000617574 ldr x9, [sp,#80] > ffff000000617578 adrp x8, ffff000000bbd000 = > ffff00000061757c add x8, x8, #0x848 > ffff000000617580 str x0, [sp,#48] > ffff000000617584 cmp x9, x8 > ffff000000617588 b.eq ffff0000006175a4 = > ffff00000061758c ldr x8, [x18] > ffff000000617590 ldr x8, [x8,#8] > ffff000000617594 ldr x8, [x8,#512] > ffff000000617598 ldr x8, [x8,#224] > ffff00000061759c cmp x8, x9 > ffff0000006175a0 b.ne ffff0000006175d8 = > ffff0000006175a4 and x8, x22, #0x1f > ffff0000006175a8 cmp x28, #0x3 > ffff0000006175ac b.ne ffff0000006175c4 = > ffff0000006175b0 cmp x8, #0xb > ffff0000006175b4 b.ne ffff0000006175d8 = > ffff0000006175b8 ldr x0, [x24] > ffff0000006175bc orr w1, wzr, #0x1000 > ffff0000006175c0 b ffff0000006175d4 = > ffff0000006175c4 cmp x8, #0x9 > ffff0000006175c8 b.ne ffff0000006175d8 = > ffff0000006175cc ldr x0, [x24] > ffff0000006175d0 orr w1, wzr, #0x200000 > ffff0000006175d4 bl ffff000000605884 = > ffff0000006175d8 mov x8, xzr > ffff0000006175dc orr w1, wzr, #0x8 > ffff0000006175e0 mov x0, x26 > ffff0000006175e4 ldxr x9, [x26] > ffff0000006175e8 stxr w10, x8, [x26] > ffff0000006175ec cbnz w10, ffff0000006175e4 = > ffff0000006175f0 bl ffff000000605884 = >=20 > So this happens to involve arm64_dcache_wb_range (that has > not started yet). I still have not replicated the example that involved instruction-cache related code. I'm going to give up on directly attempting to get examples of that. But if I happen to see it again I'll try to remember to get a backtrace (bt) for it. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed May 3 04:13:00 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7A5FD5BB59 for ; Wed, 3 May 2017 04:13:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-62.reflexion.net [208.70.210.62]) (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 59B897C0 for ; Wed, 3 May 2017 04:12:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2840 invoked from network); 3 May 2017 04:16:15 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 3 May 2017 04:16:15 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Wed, 03 May 2017 00:12:58 -0400 (EDT) Received: (qmail 1132 invoked from network); 3 May 2017 04:12:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 May 2017 04:12:58 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6C86FEC7E18; Tue, 2 May 2017 21:12:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots but gets some panics] From: Mark Millard In-Reply-To: Date: Tue, 2 May 2017 21:12:56 -0700 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <04D483DF-56BA-4A49-9DA9-6EE0AD9C38D8@dsl-only.net> References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> <9E66D0B3-3682-49DD-A792-95E29F9DC55C@dsl-only.net> <934E8CA3-A100-47F8-B6F7-F49C83AA8EF0@dsl-only.net> To: Andrew Turner , Konstantin Belousov 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, 03 May 2017 04:13:00 -0000 FYI: differences in FreeBSD's code vs.: = http://infocenter.arm.com/help/index.jsp?topic=3D/com.arm.doc.den0024a/BAB= JDBHI.html and its "Example 11.5. Cleaning by Virtual Address". . . (I do not claim to know that the differences point to any error. But I note them in case they prompt something. A couple of points do seem odd to me for the FreeBSD code.) The ARM example code does: DSB ISH DSB ISH ISB This has the property of forcing visibility only after everything is available to be visible (DSB ISH being referenced here). (The FreeBSD code does not have this property, but enforces visibility of a mix of old and new as it goes along.) It is point-of-unification code (data and instruction) for its purpose. The FreeBSD arm64_dcache__range code always pairs: DC CAVAC (or CIVAC or IVAC) DSB ISH inside it loop, forcing visibility of its intermediate state as it goes along. It is also point-of-coherency instead of point of unification (because of its purpose). The FreeBSD arm64_idcache_wbinv_range code always does the sequence of 4: DC CIVAC DSB ISH IC IVAU DSB ISH inside its loop and after the loop does one: ISB This is is a mix of point-of-coherency and point of unification code that forces visibility (DSB ISH) as it goes along, not just after the overall loop. To me the mix of point-of-coherency and point-of-unification seems strange. The FreeBSD arm64_icache_sync_range code always does the sequence of 4: DC CIVAU DSB ISH IC IVAU DSB ISH inside its loop and after the loop does one: ISB This is the closest to the "Example 11.5. Cleaning by Virtual Address" code and its purpose. It is all point-of-unification code that forces visibility (DSB ISH) as it goes long, not just after the overall loop. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed May 3 11:47:34 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 4317BD5B5BF for ; Wed, 3 May 2017 11:47:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-62.reflexion.net [208.70.210.62]) (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 E7783C8A for ; Wed, 3 May 2017 11:47:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6662 invoked from network); 3 May 2017 11:47:32 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 3 May 2017 11:47:32 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Wed, 03 May 2017 07:47:32 -0400 (EDT) Received: (qmail 500 invoked from network); 3 May 2017 11:47:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 May 2017 11:47:31 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 33690EC7E18; Wed, 3 May 2017 04:47:31 -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: svn commit: r317659 - head/sys/dev/uart [head -r317729 for armv6/7: ns8250_drain : error: implicit declaration of function 'ns8250_drain' is invalid in C99] Message-Id: Date: Wed, 3 May 2017 04:47:30 -0700 To: mav@FreeBSD.org, svn-src-head@freebsd.org, freebsd-arm , FreeBSD Current 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, 03 May 2017 11:47:34 -0000 > Author: mav > Date: Mon May 1 19:47:10 2017 > New Revision: 317659 > URL:=20 > https://svnweb.freebsd.org/changeset/base/317659 >=20 >=20 > Log: > Make some UART consoles to not spin wait for data to be sent. > =20 > At least with Tx FIFO enabled it shows me ~10% reduction of verbose = boot > time with serial console at 115200 baud. > =20 > Reviewed by: marcel > MFC after: 2 weeks >=20 > Modified: > head/sys/dev/uart/uart_dev_lpc.c > head/sys/dev/uart/uart_dev_ns8250.c After building head -r317729 for amd64 and aarch64, when I tried armv6 I instead got the following failure: --- uart_dev_lpc.o --- /usr/src/sys/dev/uart/uart_dev_lpc.c:892:4: error: implicit declaration = of function 'ns8250_drain' is invalid in C99 = [-Werror,-Wimplicit-function-declaration] ns8250_drain(bas, UART_DRAIN_TRANSMITTER); ^ /usr/src/sys/dev/uart/uart_dev_lpc.c:892:4: note: did you mean = 'lpc_ns8250_drain'? /usr/src/sys/dev/uart/uart_dev_lpc.c:140:1: note: 'lpc_ns8250_drain' = declared here lpc_ns8250_drain(struct uart_bas *bas, int what) ^ /usr/src/sys/dev/uart/uart_dev_lpc.c:892:4: error: this function = declaration is not a prototype [-Werror,-Wstrict-prototypes] ns8250_drain(bas, UART_DRAIN_TRANSMITTER); ^ 2 errors generated. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed May 3 16:39:27 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C54E2D5C1D0 for ; Wed, 3 May 2017 16:39:27 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.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 5654B13B8 for ; Wed, 3 May 2017 16:39:27 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id u65so14080325wmu.3 for ; Wed, 03 May 2017 09:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:references:to:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=FAItVlNYJdGw9mh30JcpwLWbfVRvKruitSS12P3LEUk=; b=FS0qHN3UlE8IqWUV9DgKixc0LE09Yoi4A/REm4WpDwg0ZNEJbtdsgsDEiUbcZ7iixb cZwejCD+2ljbM81y+/3qLEqy7U7X+Q7FSAObafOY/cnCOlbG0IQg8f2/N5w/s/ZStVD0 03bZ0Hw+goklN7nhgUOMWxWQtU9z8zTIEQAhDbFuiBK8XMz6ZEh57Q/4EvFAw2JHp6VM LGLM4dYditpjEpw4UIEPJRYfXwtlQYO70lX5mFMNyBLDwGgHeKCXZd4RVrRok6Q+XiTP 4E5IwiPragjc0dDA1x4UQeJ3IilHjb2X8xvMr2xsUC58Jp+jmOb6s7qw+Qm0ZliXxedn sWbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:references:to:cc :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=FAItVlNYJdGw9mh30JcpwLWbfVRvKruitSS12P3LEUk=; b=SKKy34kvrb+nWGG8+zqVv/0/j0fLHsPobKUeSDOpnsxA+xKYIyRajTMV/OhzoTNqNH ojVOHCJSo+ayn5h1YeTf8S9s2dWgqOmsnaOOP6Lt/+XSdwRzZjdKKzLdoZlLmLBvWrUD wv86BMVLYZqp7NT6dsKCJj5GnhhYPBbTvXWpo02obnGGa7mzLYtqiIcPxRYwBoNfm5s4 SwyQnML4K35+ZzYDvQk9HnhZ11xZXfICB4qJ7RmuU9db0f5GgZEGAcrJ8riUCwZcOsvT tNKNhF1cm2Ef9sqyEzlugROZ8kt1Qm7m/6jrpGVQeJFOQtC81f8L8LkmIm17/hSoUlEy s3Lg== X-Gm-Message-State: AN3rC/6araQs0qFEYrxt3xNREruFUPkwvZDXMo6jypWMpns23z5kwXgs HkxUB6CAJqXIlv3G X-Received: by 10.28.55.3 with SMTP id e3mr896164wma.7.1493829565440; Wed, 03 May 2017 09:39:25 -0700 (PDT) Received: from ?IPv6:2a02:aa16:1101:d800::5? ([2a02:aa16:1101:d800::5]) by smtp.googlemail.com with ESMTPSA id 184sm5294322wmr.30.2017.05.03.09.39.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 09:39:24 -0700 (PDT) From: Mattia Rossi X-Google-Original-From: Mattia Rossi Reply-To: mattia.rossi.mate@gmail.com Subject: Re: OrangePi-Plus-2 boot process hangs in ubldr.bin References: <20170502105007.0424f8cb7c8021951bf04495@bidouilliste.com> To: Emmanuel Vadot , mattia.rossi.mate@gmail.com Cc: ARM Message-ID: <7ee97ba7-3dd2-6df8-8d06-776d01a772be@gmail.com> Date: Wed, 3 May 2017 18:39:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170502105007.0424f8cb7c8021951bf04495@bidouilliste.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 16:39:27 -0000 On 02/05/17 10:50, Emmanuel Vadot wrote: > On Sun, 30 Apr 2017 13:07:23 +0200 > Mattia Rossi wrote: > >> Hi all, > Hello, > >> I've tried to upgrade u-boot on the OrangePi-Plus-2 (not the 2e) from >> mainline u-boot and on the outside it looks fine. > When you say mainline, what exact version did you took ? > I assume you took some patches also as it seems that your u-boot have > API support. > >> U-boot loads, and it boots ubldr.bin. >> >> I'm using the orangepi-plus-2e.dtb as it has been working well for this >> board before (It all used to work). >> >> Now ubldr can't boot the kernel though, and I don't know why. I've >> rebuilt ubldr, world and kernel from svn. Revision number is 317594 >> >> Any help would be appreciated >> >> The output before it stops is: >> >> U-Boot SPL 2017.05-rc2-00061-g12af9399e7 (Apr 25 2017 - 19:27:44) >> DRAM: 2048 MiB >> Trying to boot from MMC1 >> >> >> U-Boot 2017.05-rc2-00061-g12af9399e7 (Apr 25 2017 - 19:27:44 +0200) >> Allwinner Technology >> >> CPU: Allwinner H3 (SUN8I 1680) >> Model: Xunlong Orange Pi Plus 2E >> I2C: ready >> DRAM: 2 GiB >> MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 >> In: serial >> Out: serial >> Err: serial >> Net: phy interface7 >> eth0: ethernet@1c30000 >> starting USB... >> USB0: USB EHCI 1.00 >> USB1: USB OHCI 1.0 >> USB2: USB EHCI 1.00 >> USB3: USB OHCI 1.0 >> USB4: USB EHCI 1.00 >> USB5: USB OHCI 1.0 >> scanning bus 0 for devices... 1 USB Device(s) found >> scanning bus 2 for devices... 1 USB Device(s) found >> scanning bus 4 for devices... 1 USB Device(s) found >> scanning usb for storage devices... 0 Storage Device(s) found >> Hit any key to stop autoboot: 0 >> Booting from: mmc 0 ubldr.bin >> reading ubldr.bin >> 237168 bytes read in 34 ms (6.7 MiB/s) >> ## No elf image at address 0x42000000 >> ## Starting application at 0x42000000 ... >> Consoles: U-Boot console >> Compatible U-Boot API signature found @0xbbf3f690 >> >> FreeBSD/armv6 U-Boot loader, Revision 1.2 >> (Sat Apr 29 19:16:42 CEST 2017 root@freebsd101) >> >> DRAM: 2048MB >> MMC Device 2 not found >> MMC Device 3 not found >> Number of U-Boot devices: 2 >> U-Boot env: loaderdev='mmc 0' >> Found U-Boot device: disk >> Checking unit=0 slice= partition=... good. >> Booting from disk0s2: >> /boot/kernel/kernel data=0x6a82c0+0x1a7d40 syms=[0x4+0xba030+0x4+0xaa532] >> >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> /boot/dtb/orangepi-plus-2e.dtb size=0x6326 >> Loaded DTB from file 'orangepi-plus-2e.dtb'. >> Kernel entry at 0x42200100... >> Kernel args: (null) > This is probably a cache problem, the u-boot from ports (using imp@ > branch on github) do take care of that. > So, I've used u-boot from ports (u-boot-orangepi-one) and it boots (using dd if=u-boot-sunxi-with-spl.bin of= bs=1024 seek=8). Guess I won't find out what the differences were, but so far I don't care. Was able to use the .dtb I've compiled from the GNU .dts files I've copied over from the latest linux kernel source tree. Was a bit of macking around to get the build through, but. Now I have a fully working system. Except ZFS is not working yet ;-) Thanks for the pointers, Mat From owner-freebsd-arm@freebsd.org Wed May 3 17:15: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 A80F2D5CEFE for ; Wed, 3 May 2017 17:15:28 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CFDE2B for ; Wed, 3 May 2017 17:15:27 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 75853c13; Wed, 3 May 2017 19:15:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; s=mail; bh=povgLc 987AUp9LeybYt2VpoomhQ=; b=Y9WAqZnvfSqYcOSEJO7PJx9xZ/ka0apEP6ufIe KWUUvAjByhdAypwdaazgnwECA/59FgF/Onp6rpwPLE7pIY6o1EE2xy986PijP6gl p9fJ0MbHPTV5Gl1xJ9qYjld1pjaomPlCy2JxDZNXbpoYMmYW4Jv1sN1K4rPeKG+Y a/vYw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; q=dns; s=mail; b= pweprcsQAi0iYB72pFxkoz7spxBuOTjh7x/9+QB2fZnFqLSQwSKwx6Af92wRdlQj kriZF+ZzzEzxOS8g5AuBX3D+ElpOLAKKFqAeec7WjtX4+ag2VsAR1AePrMYuauAh Kfou9hxECkEd7ZJZRx9POvRmOgeUt4nzBKQMjqFmBvI= Received: from webmail.megadrive.org (www1.blih.net [212.83.177.180]) by mail.blih.net (OpenSMTPD) with ESMTP id 293b7bf6; Wed, 3 May 2017 19:15:18 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 03 May 2017 19:15:18 +0200 From: Emmanuel Vadot To: mattia.rossi.mate@gmail.com Cc: ARM Subject: Re: OrangePi-Plus-2 boot process hangs in ubldr.bin Organization: Bidouilliste In-Reply-To: <7ee97ba7-3dd2-6df8-8d06-776d01a772be@gmail.com> References: <20170502105007.0424f8cb7c8021951bf04495@bidouilliste.com> <7ee97ba7-3dd2-6df8-8d06-776d01a772be@gmail.com> Message-ID: X-Sender: manu@bidouilliste.com User-Agent: Roundcube Webmail/1.1.1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 17:15:28 -0000 On 2017-05-03 18:39, Mattia Rossi wrote: > On 02/05/17 10:50, Emmanuel Vadot wrote: >> On Sun, 30 Apr 2017 13:07:23 +0200 >> Mattia Rossi wrote: >> >>> Hi all, >> Hello, >> >>> I've tried to upgrade u-boot on the OrangePi-Plus-2 (not the 2e) from >>> mainline u-boot and on the outside it looks fine. >> When you say mainline, what exact version did you took ? >> I assume you took some patches also as it seems that your u-boot >> have >> API support. >> >>> U-boot loads, and it boots ubldr.bin. >>> >>> I'm using the orangepi-plus-2e.dtb as it has been working well for >>> this >>> board before (It all used to work). >>> >>> Now ubldr can't boot the kernel though, and I don't know why. I've >>> rebuilt ubldr, world and kernel from svn. Revision number is 317594 >>> >>> Any help would be appreciated >>> >>> The output before it stops is: >>> >>> U-Boot SPL 2017.05-rc2-00061-g12af9399e7 (Apr 25 2017 - 19:27:44) >>> DRAM: 2048 MiB >>> Trying to boot from MMC1 >>> >>> >>> U-Boot 2017.05-rc2-00061-g12af9399e7 (Apr 25 2017 - 19:27:44 +0200) >>> Allwinner Technology >>> >>> CPU: Allwinner H3 (SUN8I 1680) >>> Model: Xunlong Orange Pi Plus 2E >>> I2C: ready >>> DRAM: 2 GiB >>> MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 >>> In: serial >>> Out: serial >>> Err: serial >>> Net: phy interface7 >>> eth0: ethernet@1c30000 >>> starting USB... >>> USB0: USB EHCI 1.00 >>> USB1: USB OHCI 1.0 >>> USB2: USB EHCI 1.00 >>> USB3: USB OHCI 1.0 >>> USB4: USB EHCI 1.00 >>> USB5: USB OHCI 1.0 >>> scanning bus 0 for devices... 1 USB Device(s) found >>> scanning bus 2 for devices... 1 USB Device(s) found >>> scanning bus 4 for devices... 1 USB Device(s) found >>> scanning usb for storage devices... 0 Storage Device(s) >>> found >>> Hit any key to stop autoboot: 0 >>> Booting from: mmc 0 ubldr.bin >>> reading ubldr.bin >>> 237168 bytes read in 34 ms (6.7 MiB/s) >>> ## No elf image at address 0x42000000 >>> ## Starting application at 0x42000000 ... >>> Consoles: U-Boot console >>> Compatible U-Boot API signature found @0xbbf3f690 >>> >>> FreeBSD/armv6 U-Boot loader, Revision 1.2 >>> (Sat Apr 29 19:16:42 CEST 2017 root@freebsd101) >>> >>> DRAM: 2048MB >>> MMC Device 2 not found >>> MMC Device 3 not found >>> Number of U-Boot devices: 2 >>> U-Boot env: loaderdev='mmc 0' >>> Found U-Boot device: disk >>> Checking unit=0 slice= partition=... good. >>> Booting from disk0s2: >>> /boot/kernel/kernel data=0x6a82c0+0x1a7d40 >>> syms=[0x4+0xba030+0x4+0xaa532] >>> >>> Hit [Enter] to boot immediately, or any other key for command prompt. >>> Booting [/boot/kernel/kernel]... >>> /boot/dtb/orangepi-plus-2e.dtb size=0x6326 >>> Loaded DTB from file 'orangepi-plus-2e.dtb'. >>> Kernel entry at 0x42200100... >>> Kernel args: (null) >> This is probably a cache problem, the u-boot from ports (using imp@ >> branch on github) do take care of that. >> > > So, I've used u-boot from ports (u-boot-orangepi-one) and it boots > (using dd if=u-boot-sunxi-with-spl.bin of= bs=1024 seek=8). > Guess I won't find out what the differences were, but so far I don't > care. Was able to use the .dtb I've compiled from the GNU .dts files > I've copied over from the latest linux kernel source tree. Was a bit > of macking around to get the build through, but. Now I have a fully > working system. Except ZFS is not working yet ;-) > > Thanks for the pointers, > > Mat Not all patches have been upstreamed yet, I'm still working on that. And ZFS will never work on this board (or on almost any of the ARM32 boards ...) -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu May 4 04:58: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 38B81D5D67C for ; Thu, 4 May 2017 04:58:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-62.reflexion.net [208.70.210.62]) (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 E0B6012AF for ; Thu, 4 May 2017 04:58:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6667 invoked from network); 4 May 2017 04:58:50 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 4 May 2017 04:58:50 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 04 May 2017 00:58:50 -0400 (EDT) Received: (qmail 8901 invoked from network); 4 May 2017 04:58:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 May 2017 04:58:50 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8562EEC91E3; Wed, 3 May 2017 21:58:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r317659 - head/sys/dev/uart [head -r317729 for armv6/7: ns8250_drain : error: implicit declaration of function 'ns8250_drain' is invalid in C99] From: Mark Millard In-Reply-To: Date: Wed, 3 May 2017 21:58:48 -0700 Cc: svn-src-head@freebsd.org, freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <8F563A38-A8E1-4008-9BFA-D71103E9223F@dsl-only.net> References: To: mav@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, 04 May 2017 04:58:58 -0000 On 2017-May-3, at 4:47 AM, Mark Millard wrote: >> Author: mav >> Date: Mon May 1 19:47:10 2017 >> New Revision: 317659 >> URL:=20 >> https://svnweb.freebsd.org/changeset/base/317659 >>=20 >>=20 >> Log: >> Make some UART consoles to not spin wait for data to be sent. >>=20 >> At least with Tx FIFO enabled it shows me ~10% reduction of verbose = boot >> time with serial console at 115200 baud. >>=20 >> Reviewed by: marcel >> MFC after: 2 weeks >>=20 >> Modified: >> head/sys/dev/uart/uart_dev_lpc.c >> head/sys/dev/uart/uart_dev_ns8250.c >=20 >=20 > After building head -r317729 for amd64 and aarch64, > when I tried armv6 I instead got the following failure: >=20 > --- uart_dev_lpc.o --- > /usr/src/sys/dev/uart/uart_dev_lpc.c:892:4: error: implicit = declaration of function 'ns8250_drain' is invalid in C99 = [-Werror,-Wimplicit-function-declaration] > ns8250_drain(bas, UART_DRAIN_TRANSMITTER); > ^ > /usr/src/sys/dev/uart/uart_dev_lpc.c:892:4: note: did you mean = 'lpc_ns8250_drain'? > /usr/src/sys/dev/uart/uart_dev_lpc.c:140:1: note: 'lpc_ns8250_drain' = declared here > lpc_ns8250_drain(struct uart_bas *bas, int what) > ^ > /usr/src/sys/dev/uart/uart_dev_lpc.c:892:4: error: this function = declaration is not a prototype [-Werror,-Wstrict-prototypes] > ns8250_drain(bas, UART_DRAIN_TRANSMITTER); > ^ > 2 errors generated. head -r317752 appears to have fixed this: a rebuild based on -r317784 completed for armv6. Thanks. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu May 4 14:51:29 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 69954D5DC5E for ; Thu, 4 May 2017 14:51:29 +0000 (UTC) (envelope-from olavi.m.kumpulainen@gmail.com) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 D39AB104A for ; Thu, 4 May 2017 14:51:28 +0000 (UTC) (envelope-from olavi.m.kumpulainen@gmail.com) Received: by mail-lf0-x231.google.com with SMTP id j1so9474778lfh.2 for ; Thu, 04 May 2017 07:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=Gj4d0JRHLAOIImm7fJD5XKLzNObxGk0dXU2Y0WJIlAU=; b=YICdQcp5zIxZ/z7aFh8fhfMn1K3VPieTBVW/UIVTZRxuKPFhqhKJQ8rxinP8XEeVBs tNmOJA3N1ktPUq0Kw4Q5uMEzY3xy2/TcOWZN+f8BWtC0w0nvzBs9vVFAONMXwOhzO2wu m97U8JdY3aKscn7t3zFqWwEEFbybE21EeyRXlMaZKoK+z5vTu30fvz3tUWRnKudsiu7+ D+kk4KApMG51BtrLQ5QcFkOLoaeWvFzsTXXd/y9uPNC9DZdc082ubDA1do0CmSzEllWS EAWPCP5g7PxnKBFSGTldzGvBdd1oH/BjzLKYN2rJ1qRLCIe1JUgqSOodHMjFtbL1VCHO nGiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=Gj4d0JRHLAOIImm7fJD5XKLzNObxGk0dXU2Y0WJIlAU=; b=Gj3T8nZ1wSaHoSyEFW5TJ+O5csn09ee8mBCO6ONVpEmIPRu1ha96ra4Wl2ASXVeDW9 DLthMJNmXRPUV5LV2f499JOO479Lv12Nh15gAHkmFLv7iT/oes+k+ty6La+8pFNPtkVM 4xIEkJFbtqblORncVidb0RPW1lHzCRSDNnUmKAUsXdfV8imIAhFOFZbkyJJ1gGavrcl+ EfhDky0q68KZREUKT2Ouahgmr4mcKoDEh2iY0dy/iKJ0r+SDDOiLG/X3gw1C012jpMdp VS7N1Zsfa09oaEorgimKoQagF8KoMlxLdn2lU+OcUt15J5lT/PbLdaqvxCwWY9rL0Yo8 x5HQ== X-Gm-Message-State: AN3rC/5JjVLDSuftNvwlH9hoQPZ9mw2ipGjTVGqJhn366WD6gTfVDF/l Bm61ab2NxyhA6N9dfhU= X-Received: by 10.46.22.76 with SMTP id 12mr15368423ljw.55.1493909486654; Thu, 04 May 2017 07:51:26 -0700 (PDT) Received: from [192.168.1.112] (c83-251-251-174.bredband.comhem.se. [83.251.251.174]) by smtp.gmail.com with ESMTPSA id v6sm75244ljd.17.2017.05.04.07.51.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 May 2017 07:51:25 -0700 (PDT) To: freebsd-arm@FreeBSD.org From: Olavi Kumpulainen Subject: cpsw drops packets when stressed on BBB and 11.0-STABLE Message-ID: <25b417df-9073-0e3e-39f7-64ca241d516d@gmail.com> Date: Thu, 4 May 2017 16:51:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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, 04 May 2017 14:51:29 -0000 Hi, I'm running a snapshot build of FreeBSD-11, FreeBSD beaglebone 11.0-STABLE FreeBSD 11.0-STABLE #0 r317153: Thu Apr 20 09:21:26 UTC 2017 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE arm on a BBB. I see that cpsw drops outgoing packets when stressed. Out of some reason, dev.cpswss.0.stats.RxStartOfFrameOverruns increments when packets are dropped which may be a hint on what’s going on. The fact that RxStartOf... increases is confusing, because the packets seem to be dropped in transmission. Anyway - I’ve found a simple way to reproduce the problem, namely by sending long pings. On the BBB: # tcpdump -ni cpsw0 icmp& Initial state of RxStartOfFrameOverruns in BBB after playing around a bit: # sysctl dev.cpswss.0.stats.RxStartOfFrameOverruns dev.cpswss.0.stats.RxStartOfFrameOverruns: 86 # ping -c 1 -s 14000 192.168.0.3 PING 192.168.0.3 (192.168.0.3): 14000 data bytes 11:36:57.965980 IP 192.168.0.158 > 192.168.0.3: ICMP echo request, id 53762, seq 0, length 1480 11:36:57.966658 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 11:36:57.966826 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 11:36:57.966923 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 11:36:57.967009 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 11:36:57.967090 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 11:36:57.967173 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 11:36:57.967254 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 11:36:57.967336 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 11:36:57.967414 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 (10 packets has supposedly been put into the tx ring in BBB) Looking at RxStartOfFrameOverruns in the BBB, I see an increment by 5… #sysctl dev.cpswss.0.stats.RxStartOfFrameOverruns dev.cpswss.0.stats.RxStartOfFrameOverruns: 91 I've set up a tcpdump on the target machine: $ sudo tcpdump -ni eth2 icmp 13:52:42.603199 IP 192.168.0.158 > 192.168.0.3: ICMP echo request, id 53762, seq 0, length 1480 13:52:42.604697 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 (Eight fragments lost!) Without tcpump in BBB, more packets seem to go through (showing tcpdump on target); 13:56:08.396553 IP 192.168.0.158 > 192.168.0.3: ICMP echo request, id 55554, seq 0, length 1480 13:56:08.397781 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 13:56:08.399029 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 13:56:08.400157 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 13:56:08.401409 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 (Five packets lost) Again, there's an increment in RxStartOfFrame...: # sysctl dev.cpswss.0.stats.RxStartOfFrameOverruns dev.cpswss.0.stats.RxStartOfFrameOverruns: 96 I added a printf in tx_enqueue() in an attempt to see what’s going on, but doing so “fixed the bug” – obviously by adding a delay in the forwarding code. Maybe we have a timing/race between the driver and the cpsw hardware? Also, I tested sending 14k pings from the standard-installed Linux in the BBB and that worked just fine. So the packets aren't lost between the hosts (the machines are connected via the same switch). Any ideas? Cheers - /Olavi From owner-freebsd-arm@freebsd.org Thu May 4 15:57:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16491D5D0E0 for ; Thu, 4 May 2017 15:57:24 +0000 (UTC) (envelope-from mathieudube1977@gmail.com) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 A2DA5226 for ; Thu, 4 May 2017 15:57:23 +0000 (UTC) (envelope-from mathieudube1977@gmail.com) Received: by mail-wr0-x236.google.com with SMTP id l50so10355406wrc.3 for ; Thu, 04 May 2017 08:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=VjvM5/N2kcD6APAWCj+SO2wKfFEx/BOS23wPs/lpMUI=; b=vWB6bwecmPuT4o/dTlCU1SNWsSJNRzYO1IdKMNEfuINXYsRZJFhKbZMCihdFbKujoe US8PprHMFh5QX54OPWBNy9kCZpF1o4fkQ9YB4UNHagZ46ngrqpdfnyCEi4XlbJpePePg sTfPnqBq7sae/tApFNMcODn+yTyyookLgRNUOdZOecDrTMYCRNqjXftSI9WoyiT7ydg+ UjlkQqsaoWKLhUsBARwinJ8qLSDJggdIjyQR0tDQ/WH8Jt7mtkJvTONNufyKjlZTj3Zm DoHLJFhwZIDaBy124kU0Thk5tAwpVFdRiZoUXQQDGLjRSw4n34EQx6fPD6oufvdWNcvc /i/Q== 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=VjvM5/N2kcD6APAWCj+SO2wKfFEx/BOS23wPs/lpMUI=; b=T5plvgP31FViZ1TgsKIneuXqYTjUDu7AacNQP4QWbif5Ctc62g+GaCXTfyRsjUAe8P ec9QwpnrlWVxEm9BzeK9I4LnKRQKPDEPZBiRcI4iqTQT4Aea3sisZGsKoA4k7svZRL1i nP1063zU3cSiKzhmFLSZuMmurmK9got6BWQ5j6fEdmbzq99thBsAiZ+/Lmwxo1uNK+eL C6Ow7Z31gvlLbzDBhJ7e1OijAL+OvoGlyoHDsi64yhE9ekiiXVUAy4SYe//mrTg9XDof NHgX4bWx64eZstXKF6ltxpfLO60tRIu82DeSEkDZi0eHwcfJer202AfSNvsHoXzPDDvW Ju6w== X-Gm-Message-State: AN3rC/4nbHNRtKl0v6F+MxQuF3xiPkOq5XZIPFVSfYfLyBOLC/Z1b4Bn 0uK2l4HpuCF9bbX1fVuRj3HHXnvefkPl X-Received: by 10.223.176.83 with SMTP id g19mr27041657wra.12.1493913441680; Thu, 04 May 2017 08:57:21 -0700 (PDT) MIME-Version: 1.0 Sender: mathieudube1977@gmail.com Received: by 10.28.158.3 with HTTP; Thu, 4 May 2017 08:57:21 -0700 (PDT) From: Matt Dube Date: Thu, 4 May 2017 11:57:21 -0400 X-Google-Sender-Auth: yeG1a13jF22VqF6XAkditq0-ZQw Message-ID: Subject: SIGBUS on crochet for rpi3 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: Thu, 04 May 2017 15:57:24 -0000 Hi, I'm not sure if I'm doing something obviously wrong but I get the following when I try to build the image for rpi3 with crochet. I've only ever seen SIGBUS on compilation on a parallel fs when a node rebuilds an object file while another one is trying to use it so I'm not sure what's causing this. Anyone has seen this? Thanks -Matt --- CodeGen/CGObjCMac.o --- c++ -O2 -pipe -I/usr/src/crochet/work/obj/arm64.aarch64/usr/src/tmp/usr/src/lib/ clang/libclang -I/usr/src/crochet/work/obj/arm64.aarch64/usr/src/tmp/usr/src/lib/ clang/libllvm -I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/in clude -I/usr/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_L IMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"aarch64-unkno wn-freebsd12.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DDEFAULT_SYSR OOT=\"/usr/src/crochet/work/obj/arm64.aarch64/usr/src/tmp\" -ffunction-sections - fdata-sections -MD -MF.depend.CodeGen_CGObjCMac.o -MTCodeGen/CGObjCMac.o -Qunused -arguments -I/usr/src/crochet/work/obj/arm64.aarch64/usr/src/tmp/legacy/usr/inclu de -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGObjCMac.cpp -o CodeGen/CGObjCMac .o --- CodeGen/CGExprScalar.o --- c++: error: unable to execute command: Bus error (core dumped) c++: error: clang frontend command failed due to signal (use -v to see invocation ) FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) Target: x86_64-unknown-freebsd11.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org /submit/ and include the crash backtrace, preprocessed source, and associated run script. c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/CGExprScalar-4d931a.cpp c++: note: diagnostic msg: /tmp/CGExprScalar-4d931a.sh c++: note: diagnostic msg: ******************** *** [CodeGen/CGExprScalar.o] Error code 254 make[4]: stopped in /usr/src/lib/clang/libclang 1 error From owner-freebsd-arm@freebsd.org Thu May 4 16:10:59 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66679D5D45C for ; Thu, 4 May 2017 16:10:59 +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 E5F9FAC9 for ; Thu, 4 May 2017 16:10:58 +0000 (UTC) (envelope-from olavi.m.kumpulainen@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id h4so10905690lfj.3 for ; Thu, 04 May 2017 09:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=P6+SnUXKgk/O4MsQTaBmqfT8Unef9piJAPcbLD9fLlg=; b=IotPxgNOuyPWKr/MnPMs5ujFh9eypNckCYlCk24STlRWuw/BZ2vuE5hrJ/HXOC+ZX2 TDOqpUA/uOdWtavoUvs7VQfQNxUlRvR3SPsGftZuhq9x8X0km+HJIR2NjhaoBEsngFsT YNTJbd7xrkWwcIiXYlyHFe7pW7PEL6GFxNPFByQFvH0HZQH0bC/MC3dKTJmgVkEZoqQ0 cwp9UZTNN+zR3gkEEtQcqlocWGmozAkYVEjHHjOHbserlJ32ylaTYO7U3Cx8Pjikpl6Q Ji3AK4sO6SLJ4RH8cqN68wcjXRPvBjccL2K/xkQI0Bp+z/WrB8v5ynks8ZXSUjZs8A2J jLKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=P6+SnUXKgk/O4MsQTaBmqfT8Unef9piJAPcbLD9fLlg=; b=TVE2/AtM2UoyV03MCPh/rULarZcGelfsgAYD06kEnY91H617cs+xLSwly+eI44Nkus rVw4B79kMCJvCgKMWJCGt3Ig150zYgXK/w8ae1sfOh9FG0O7l2G8RO9qUOUH/rpBpT/D m/Ahtznma0Es/XB0igZ6Ax5d90lfKOUpNnz+NvMaU7IYlmFf+JbUBnop3FS0O7U+XJGh SkSYp1Wc2lzWg0S6dgkG0gSmrp1SD94vN8aPA8UozYJAcEOUauM13GuWlU2A7cd/Hqc2 ijDuRh3VV4MlsssPi9S5FxD2S4oxRNDMA/wNiE6H/04Fco8Y9qy0AWNIBQGofyTfNLo2 MJoQ== X-Gm-Message-State: AN3rC/7Y41VzXgdlvhem+HfhZQ9gzJ70WdopWS9KJOqM4giB3hGvNUjx boDFylQUrinVCGxEMdc= X-Received: by 10.25.40.129 with SMTP id o123mr12881553lfo.155.1493914256576; Thu, 04 May 2017 09:10:56 -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 r190sm518157lfr.8.2017.05.04.09.10.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 May 2017 09:10:54 -0700 (PDT) From: Olavi Kumpulainen Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: cpsw drops packets when stressed on BBB and 11.0-STABLE Message-Id: Date: Thu, 4 May 2017 18:10:55 +0200 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 16:10:59 -0000 Hi, I'm running a snapshot build of FreeBSD-11, FreeBSD beaglebone 11.0-STABLE FreeBSD 11.0-STABLE #0 r317153: Thu Apr = 20 09:21:26 UTC 2017 =20 on a BBB. I see that cpsw drops outgoing packets when stressed. =20 Out of some reason, dev.cpswss.0.stats.RxStartOfFrameOverruns increments = when packets are dropped which may be a hint on what=E2=80=99s going on.=20= The fact that RxStartOf... increases is confusing, because the packets = seem to be dropped in transmission.=20 Anyway - I=E2=80=99ve found a simple way to reproduce the problem, = namely by sending long pings. On the BBB: # tcpdump -ni cpsw0 icmp&=20 Initial state of RxStartOfFrameOverruns in BBB after playing around a = bit: # sysctl dev.cpswss.0.stats.RxStartOfFrameOverruns=20 dev.cpswss.0.stats.RxStartOfFrameOverruns: 86 =20 # ping -c 1 -s 14000 192.168.0.3 PING 192.168.0.3 (192.168.0.3): 14000 data bytes 11:36:57.965980 IP 192.168.0.158 > 192.168.0.3: ICMP echo request, id = 53762, seq 0, length 1480 11:36:57.966658 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 11:36:57.966826 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 11:36:57.966923 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 11:36:57.967009 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 11:36:57.967090 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 11:36:57.967173 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 11:36:57.967254 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 11:36:57.967336 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 11:36:57.967414 IP 192.168.0.158 > 192.168.0.3: ip-proto-1=20 (10 packets has supposedly been put into the tx ring in BBB)=20 Looking at RxStartOfFrameOverruns in the BBB, I see an increment by 5=E2=80= =A6 #sysctl dev.cpswss.0.stats.RxStartOfFrameOverruns=20 dev.cpswss.0.stats.RxStartOfFrameOverruns: 91 =20 I've set up a tcpdump on the target machine: $ sudo tcpdump -ni eth2 icmp 13:52:42.603199 IP 192.168.0.158 > 192.168.0.3: ICMP echo request, id = 53762, seq 0, length 1480 13:52:42.604697 IP 192.168.0.158 > 192.168.0.3: ip-proto-1=20 (Eight fragments lost!) Without tcpump in BBB, more packets seem to go through (showing tcpdump = on target); 13:56:08.396553 IP 192.168.0.158 > 192.168.0.3: ICMP echo request, id = 55554, seq 0, length 1480 13:56:08.397781 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 13:56:08.399029 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 13:56:08.400157 IP 192.168.0.158 > 192.168.0.3: ip-proto-1 13:56:08.401409 IP 192.168.0.158 > 192.168.0.3: ip-proto-1=20 (Five packets lost)=20 Again, there's an increment in RxStartOfFrame...: # sysctl dev.cpswss.0.stats.RxStartOfFrameOverruns=20 dev.cpswss.0.stats.RxStartOfFrameOverruns: 96 =20 I added a printf in tx_enqueue() in an attempt to see what=E2=80=99s = going on, but doing so =E2=80=9Cfixed the bug=E2=80=9D =E2=80=93 = obviously by adding a delay in the forwarding code. Maybe we have a = timing/race between the driver and the cpsw hardware? Also, I tested sending 14k pings from the standard-installed Linux in = the BBB and that worked just fine. So the packets aren't lost between = the hosts (the machines are connected via the same switch). Any ideas? Cheers - /Olavi From owner-freebsd-arm@freebsd.org Thu May 4 23:38:16 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD0E5D5E6BF for ; Thu, 4 May 2017 23:38:16 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FC7B168D for ; Thu, 4 May 2017 23:38:16 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-ua0-x232.google.com with SMTP id p8so19707883uaa.3 for ; Thu, 04 May 2017 16:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=to:from:subject:message-id:date:user-agent:mime-version; bh=mSeGbgZuFyl/KMF0rE9RfBlYmo4Rv71+NZbh4vA1Ifo=; b=A2iNDhYc9h56TA0TqQDcoq3Nx+hyfNgszPYLlEdxXg7X2xAN/lPEuL8b8qDLw9fXJz BjKI05WGlT0jLPixwQMW7vYD6MDolwVdyTEsHRHadtyRY0xr7B/JwkTtT6Fey/c5e77w If7A5s2gtAKuC4Pq5wTq68zLD//+2M8a7H3js= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=mSeGbgZuFyl/KMF0rE9RfBlYmo4Rv71+NZbh4vA1Ifo=; b=uPuwkRmWdsLhMvfZxILp/zp3HTNgilEHZqo3WEKnvmCqoMEY+O1XO1cTp/7hPMow5a 2rh8V1hEVb0nCblXoCZLa/SuYE5mwOJbGUz8ql3Oc2RNBSlwsxEgWFBxNiPbXsBTDAlA lKQKIkdSF5HTAj+8zoMdBAe7oRWAlYD15acnQX/aptVsBTKheSCRoLdCwiE8pX36imB+ R+vol8XolPyYtWyl+hQ9I1JPMSKGQD03fgi6L3UrrnjLBwtbR9xWNtfmr9juYXvjD1/X H2jbl3qfoW/DexWV8vUIkLXuOOnMMqlxWPZ/wdGMEy9/r+lrJBiif9hgTHioec5G2xaG 8G7w== X-Gm-Message-State: AN3rC/6X0txmsL0HY9GNQFohJSOaH3j7qnEkTaWehlMuRR2S56WQWQc4 i9pdnd3tY8BoLbse X-Received: by 10.176.68.65 with SMTP id m59mr19849860uam.127.1493941095087; Thu, 04 May 2017 16:38:15 -0700 (PDT) Received: from ?IPv6:2804:54:19ef:cc00:79bc:6e25:7dc1:b17d? ([2804:54:19ef:cc00:79bc:6e25:7dc1:b17d]) by smtp.googlemail.com with ESMTPSA id v142sm1667544vke.24.2017.05.04.16.38.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 May 2017 16:38:14 -0700 (PDT) To: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Subject: multimedia/openh264 crashes FreeBSD 12 on arm64 Message-ID: Date: Thu, 4 May 2017 20:38:00 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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, 04 May 2017 23:38:16 -0000 Hello guys I am compiling some ports on my raspberry pi 3 and some bugs have appeared. In the meantime I have found a port that all times when I try to compile its raises a kernel panic. This is multimedia/openh264. To reproduce, simply turn on the plugins and test options and try to compile. The kernel panic happens when it is doing the tests. The openh264 port revision I am using is r439777 and freebsd is 12 r317063. []'s -Otacilio From owner-freebsd-arm@freebsd.org Fri May 5 03:32:59 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFBDFD5D0E4 for ; Fri, 5 May 2017 03:32:59 +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 8D71216F2 for ; Fri, 5 May 2017 03:32:59 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id 142so11650824wma.1 for ; Thu, 04 May 2017 20:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QXykxY8GGsDBIJq9OyVqivPnsts7myU0gou5GsiplWY=; b=EeWbJoYEzhKjMEdHvPpF9rnz7VQFsI0tQpf1073DzhLZHp45vr2W6nDETEnnCsFTda JE/b1K6p+yxktH/DGOPtVD//rtjwUI1eTwehGeIaTrCVjhmUgTyMR0m44prNjaz8NQZJ 0wctuvwME0l5zxgDsAw1W+oS12UawQOdLMG73UFqYZBz4bGHp/oxc2vnpQXk0itna+3m +R9dfh4EzX94uzxnC546u7s3kuSnes8sdc73ZRshxyfWc3fcH8qeD9d/ZaV5TCIBXnvo ypie4cmlkbxMxDmmv/jPk/tiTfOCGbLiEAmSdJSdM/+yHg2qQzAk59m6/ES/0QIw/iCJ rAxQ== 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=QXykxY8GGsDBIJq9OyVqivPnsts7myU0gou5GsiplWY=; b=cVW8m9KPK6fz/oKw4kVRqg6rFy3Jl0LimZ3kbjyjYDSUz7rBSuxB47ecoI//Vd2PTi RfsKJLTaf+EGJ+w4Mg9NnM3FkXbRBgh2Rjs4wSbDgP3n+5iuEwOeW+m+yhVtLS5Kz6s8 gWKIzL3Zya/iioqTGXef9xTUUPNutrAxruP/BasBFDwHyEKgDL52/+jXqbuxqs+GRO47 3GTlkIpTFDtOburspcPeCM/NUWOO4xqI7pG/K8US6vWV+ZgE4++RYX2GVFycZiGR1eX+ utQJfzengLlE+LXZoZXXCwB+zsIRw6I9MciRcZDVKke/1waYdM9LHvmqXoxXm1KAFkHo Egbg== X-Gm-Message-State: AN3rC/4sJcqaG6jjBBYjI7Fu3Bf/kWN/7MqlG4hQrYLVhYf/3T3SK46N 8/npu1WFRq/COd4Lg1cy58qSdTsNWA== X-Received: by 10.80.187.68 with SMTP id y62mr7918142ede.51.1493955177507; Thu, 04 May 2017 20:32:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.149.219 with HTTP; Thu, 4 May 2017 20:32:56 -0700 (PDT) In-Reply-To: <25b417df-9073-0e3e-39f7-64ca241d516d@gmail.com> References: <25b417df-9073-0e3e-39f7-64ca241d516d@gmail.com> From: Luiz Otavio O Souza Date: Fri, 5 May 2017 00:32:56 -0300 Message-ID: Subject: Re: cpsw drops packets when stressed on BBB and 11.0-STABLE To: Olavi Kumpulainen Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 03:33:00 -0000 On 4 May 2017 at 11:51, Olavi Kumpulainen wrote: > Hi, > > I'm running a snapshot build of FreeBSD-11, > FreeBSD beaglebone 11.0-STABLE FreeBSD 11.0-STABLE #0 r317153: Thu Apr 20 > 09:21:26 UTC 2017 > root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE arm > > on a BBB. > > I see that cpsw drops outgoing packets when stressed. > I'll take a look, just can't promise a date. A similar issue was already identified in pfSense (we are digging...). Regards, Luiz From owner-freebsd-arm@freebsd.org Fri May 5 10:37: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 14E40D5E608 for ; Fri, 5 May 2017 10:37:54 +0000 (UTC) (envelope-from secretaria@ampformosa.com.ar) Received: from ws122.host4g.com (ws122.host4g.com [190.210.9.102]) by mx1.freebsd.org (Postfix) with ESMTP id D85121AA2 for ; Fri, 5 May 2017 10:37:53 +0000 (UTC) (envelope-from secretaria@ampformosa.com.ar) Received: from ws65.host4g.com (ws65.host4g.com [190.210.9.40]) by ws122.host4g.com (Postfix) with ESMTP id D540598D20EC1 for ; Fri, 5 May 2017 07:37:59 -0300 (ART) Received: from [142.0.42.11] (unknown [142.0.42.11]) by ws65.host4g.com (Postfix) with ESMTPA id C300442A1795 for ; Fri, 5 May 2017 07:37:06 -0300 (ART) Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Description: Mail message body Subject: Request To: freebsd-arm@freebsd.org From: "Sir. Paul Judge" Date: Fri, 05 May 2017 03:37:38 -0700 Reply-To: sirpaulrjudge@outlook.com 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, 05 May 2017 10:37:54 -0000 Hello, Good Day to you and I hope this message meet you well. I hope this mail meets you well. Before I proceed, I will like to introduce= my self for better understanding, My name is Sir. Paul R. Judge, Non Indep= ent Executive Director with Standard Bank Group in South East Asia,one of t= he biggest independent financial institution, I am contacting you because I= want you to assist me in receiving a deposit of one of our late client A C= hinese National who died in 2005. Before his death he has a deposit of (Twe= nty Two Million Seven Hundred and Twenty Eight Thousand Four Hundred and Fo= urteen United States Dollars)in our bank. Though I know that a transaction = of this magnitude will make any one apprehensive and worried, but I am assu= ring you that all will be well at the end of the day. On July 7, 2005, series of coordinated terrorist bomb blasts hit the London= Subways, resulting in the loss of more than 52 people and unfortunately ou= r late client was among the people that died on that fateful day while he w= as in United Kingdom for a business meeting, all efforts to contact his rel= atives/family representatives turned unsuccessful, I have made several inqu= iries to your embassy to locate any his extended relatives but has been uns= uccessful. After several unsuccessful attempts, I decided to trace his last= name over the internet, to see if I could locate any member of his family = hence I contacted you as you have thesame last name with our late client. His account where his deposit of (Twenty Two Million Seven Hundred and Twen= ty Eight Thousand Four Hundred and Fourteen United States Dollars)USD22,728= .414.00 is no longer active and inoperative. My bank will declare the accou= nt unserviceable and thereby send the funds to the bank treasury if I do no= t present anyone as family representative or relative to our late client. I= will seek your consent to present you as the relative or family representa= tive of our late client since you share the same last name with the our lat= e client so that the funds on the account can be paid to you then you and I= can share the money for investment purposes in your country. If you can handle this with me, I will want you to send me a reply with, (Y= OUR FULL NAMES: CONTACT ADDRESS: DATE OF BIRTH: OCCUPATION: MOBILE/HOME TE= LEPHONE NUMBER) to enable me submit to my bank immediately for the release = of the funds to you as his relative and family representative. Please I do not want any direct link between us, my official lines are not = secured as they are periodically monitored please observe this instruction = religiously, all legal documents and paper work will be released to you as = soon as I receive your response with the required information. Thank you and I hope to read from you, Kindly send me all details to: sirpaulrjudge@outlook.com Regards, Sir Paul R. Judge, Non Independent Executive Director, Standard Bank Group. South East Asia. From owner-freebsd-arm@freebsd.org Fri May 5 12:00:14 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D981D5F0FC for ; Fri, 5 May 2017 12:00:14 +0000 (UTC) (envelope-from secretaria.centrosalud@ampformosa.com.ar) Received: from ws122.host4g.com (ws122.host4g.com [190.210.9.102]) by mx1.freebsd.org (Postfix) with ESMTP id D93EB22A for ; Fri, 5 May 2017 12:00:13 +0000 (UTC) (envelope-from secretaria.centrosalud@ampformosa.com.ar) Received: from ws65.host4g.com (ws65.host4g.com [190.210.9.40]) by ws122.host4g.com (Postfix) with ESMTP id 2B5FC99124F58 for ; Fri, 5 May 2017 08:59:41 -0300 (ART) Received: from [142.0.42.11] (unknown [142.0.42.11]) by ws65.host4g.com (Postfix) with ESMTPA id 501A542A179B for ; Fri, 5 May 2017 08:58:47 -0300 (ART) MIME-Version: 1.0 Subject: Google User To: freebsd-arm@freebsd.org From: "Google Inc" Date: Fri, 05 May 2017 04:59:18 -0700 Reply-To: admin@gpawardteam.com Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: Mail message body 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, 05 May 2017 12:00:14 -0000 Dear Google User, We congratulate you for being selected as one of our winner on the ongoing = award promotion. Find attached document with more information regarding you= r winning. Congratulation, Sundar Pichai, Chief Executive Officer, Google Inc. From owner-freebsd-arm@freebsd.org Fri May 5 15:24: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 EDFF4D5F35B; Fri, 5 May 2017 15:24:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BB316A8A; Fri, 5 May 2017 15:24:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v45FDdxA051284 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 May 2017 08:13:40 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v45FDds9051283; Fri, 5 May 2017 08:13:39 -0700 (PDT) (envelope-from fbsd) Date: Fri, 5 May 2017 08:13:39 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Cc: ports@freebsd.org, bob prohaska Subject: RPI2, www/firefox, error: "NEON support not enabled" Message-ID: <20170505151339.GA51255@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 15:24:44 -0000 In trying to compile www/firefox on RPI2 running -current the build now stops with error: "NEON support not enabled" The port at www/neon is compiled and installed. Thanks for reading, any guidance appreciated. bob prohaska From owner-freebsd-arm@freebsd.org Fri May 5 16:30:42 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB601D5FA42 for ; Fri, 5 May 2017 16:30:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-78.reflexion.net [208.70.210.78]) (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 7C7C5D6D for ; Fri, 5 May 2017 16:30:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12766 invoked from network); 5 May 2017 16:34:00 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 May 2017 16:34:00 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 05 May 2017 12:30:40 -0400 (EDT) Received: (qmail 17220 invoked from network); 5 May 2017 16:30:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 May 2017 16:30:40 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C6B17EC8E6A; Fri, 5 May 2017 09:30:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RPI2, www/firefox, error: "NEON support not enabled" From: Mark Millard In-Reply-To: <20170505151339.GA51255@www.zefox.net> Date: Fri, 5 May 2017 09:30:39 -0700 Cc: freebsd-arm@freebsd.org, ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <962F9C0D-C7C8-4940-A381-B3097FD2A138@dsl-only.net> References: <20170505151339.GA51255@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 16:30:42 -0000 On 2017-May-5, at 8:13 AM, bob prohaska wrote: > In trying to compile www/firefox on RPI2 running -current the build = now stops > with >=20 > error: "NEON support not enabled" >=20 > The port at www/neon is compiled and installed. Wrong neon. > Thanks for reading, any guidance appreciated. https://developer.arm.com/technologies/neon says: ARM NEON technology is an advanced SIMD (single instruction multiple = data) architecture extension for the ARM Cortex-A series and Cortex-R52 = processors. NEON technology was introduced to the ARMv7-A and ARMv7-R profiles. It = is also now an extension to the ARMv8-A and ARMv8-R profiles. So here NEON is a subset of the instruction set. Its purpose is (again quoting that page): NEON technology is intended to improve the multimedia user experience by accelerating audio and video encoding/decoding, user interface, 2D/3D graphics or gaming. NEON can also accelerate signal processing = algorithms and functions to speed up applications such as audio and video = processing, voice and facial recognition, computer vision and deep learning. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri May 5 18:28:41 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 DDFDCD5F0C7; Fri, 5 May 2017 18:28:41 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B42052FA; Fri, 5 May 2017 18:28:41 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v45IScKO051867 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 May 2017 11:28:39 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v45IScoc051866; Fri, 5 May 2017 11:28:38 -0700 (PDT) (envelope-from fbsd) Date: Fri, 5 May 2017 11:28:38 -0700 From: bob prohaska To: Mark Millard Cc: ports@freebsd.org, freebsd-arm@freebsd.org Subject: Re: RPI2, www/firefox, error: "NEON support not enabled" Message-ID: <20170505182838.GB51255@www.zefox.net> References: <20170505151339.GA51255@www.zefox.net> <962F9C0D-C7C8-4940-A381-B3097FD2A138@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <962F9C0D-C7C8-4940-A381-B3097FD2A138@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 18:28:42 -0000 On Fri, May 05, 2017 at 09:30:39AM -0700, Mark Millard wrote: > > Wrong neon. > > Ahh, what I feared 8-) > https://developer.arm.com/technologies/neon says: > I did find that page, but harbored a faint (and apparently misguided) hope that the port might in some fashion implement the vector instruction set. Evidently not. Thanks for clearing up the confusion. Is this an issue which must be addressed by the clang/llvm developers? 8-( bob prohaska From owner-freebsd-arm@freebsd.org Fri May 5 19:38: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 A9430D5F632 for ; Fri, 5 May 2017 19:38:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-77.reflexion.net [208.70.210.77]) (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 5E11916EA for ; Fri, 5 May 2017 19:38:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2815 invoked from network); 5 May 2017 19:41:35 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 May 2017 19:41:35 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 05 May 2017 15:38:15 -0400 (EDT) Received: (qmail 2453 invoked from network); 5 May 2017 19:38:15 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 May 2017 19:38:15 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A6B9DEC917D; Fri, 5 May 2017 12:38:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RPI2, www/firefox, error: "NEON support not enabled" From: Mark Millard In-Reply-To: <20170505182838.GB51255@www.zefox.net> Date: Fri, 5 May 2017 12:38:14 -0700 Cc: ports@freebsd.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <078B736E-4807-42C7-B6A5-656F3A50DAEB@dsl-only.net> References: <20170505151339.GA51255@www.zefox.net> <962F9C0D-C7C8-4940-A381-B3097FD2A138@dsl-only.net> <20170505182838.GB51255@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 19:38:17 -0000 On 2017-May-5, at 11:28 AM, bob prohaska wrote: > On Fri, May 05, 2017 at 09:30:39AM -0700, Mark Millard wrote: >> >> Wrong neon. >> >> > Ahh, what I feared 8-) > > >> https://developer.arm.com/technologies/neon says: >> > > I did find that page, but harbored a faint (and apparently > misguided) hope that the port might in some fashion implement > the vector instruction set. Evidently not. Freshports web page for it ( https://www.freshports.org/www/neon/ ) reports: Neon is an HTTP and WebDAV client library for Unix systems, with a C interface. > Thanks for clearing up the confusion. Is this an issue which > must be addressed by the clang/llvm developers? An rpi2 has Cortex-A7 (armv7-A) cores that have NEON but armv6 does not. There is some possibility that with something like -mcpu=cortex-a7 in use as a compiler option that NEON would be used. But I warn that there is an on-going bugzilla item for FreeBSD's support of things like NEON for arm: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217611 (VFP and NEON are related by the registers used.) So there could be other problems with NEON enabled code until it is all resolved. (And head gets the work before stable/11 gets the result.) === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri May 5 23:01:09 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E455BD5FB3C; Fri, 5 May 2017 23:01:09 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C084CC70; Fri, 5 May 2017 23:01:09 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v45N17Zf052598 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 May 2017 16:01:07 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v45N16JC052597; Fri, 5 May 2017 16:01:06 -0700 (PDT) (envelope-from fbsd) Date: Fri, 5 May 2017 16:01:06 -0700 From: bob prohaska To: Mark Millard Cc: ports@freebsd.org, freebsd-arm@freebsd.org Subject: Re: RPI2, www/firefox, error: "NEON support not enabled" Message-ID: <20170505230106.GA52464@www.zefox.net> References: <20170505151339.GA51255@www.zefox.net> <962F9C0D-C7C8-4940-A381-B3097FD2A138@dsl-only.net> <20170505182838.GB51255@www.zefox.net> <078B736E-4807-42C7-B6A5-656F3A50DAEB@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <078B736E-4807-42C7-B6A5-656F3A50DAEB@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 23:01:10 -0000 On Fri, May 05, 2017 at 12:38:14PM -0700, Mark Millard wrote: > > An rpi2 has Cortex-A7 (armv7-A) cores that have NEON > but armv6 does not. > > There is some possibility that with something like > -mcpu=cortex-a7 in use as a compiler option that > NEON would be used. What's the simplest way to try it on a self-hosted RPI2 running -current? At this point I'm just using make -DBATCH in /usr/ports/www/firefox and following my nose. There's nothing valuable on the system, it's only for testing. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217611 > > (VFP and NEON are related by the registers used.) > > So there could be other problems with NEON enabled code > until it is all resolved. (And head gets the work before > stable/11 gets the result.) > Most of the discussion in the thread is beyond me, but it is appreciated that the problem isn't simple. Thanks for writing! bob prohaska From owner-freebsd-arm@freebsd.org Sat May 6 00:44:26 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49806D5D8B4 for ; Sat, 6 May 2017 00:44:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-78.reflexion.net [208.70.210.78]) (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 E63F188C for ; Sat, 6 May 2017 00:44:25 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30613 invoked from network); 6 May 2017 00:44:18 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 6 May 2017 00:44:18 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 05 May 2017 20:44:18 -0400 (EDT) Received: (qmail 22115 invoked from network); 6 May 2017 00:44:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 May 2017 00:44:18 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5DAA8EC7ED9; Fri, 5 May 2017 17:44:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RPI2, www/firefox, error: "NEON support not enabled" From: Mark Millard In-Reply-To: <20170505230106.GA52464@www.zefox.net> Date: Fri, 5 May 2017 17:44:16 -0700 Cc: ports@freebsd.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <20170505151339.GA51255@www.zefox.net> <962F9C0D-C7C8-4940-A381-B3097FD2A138@dsl-only.net> <20170505182838.GB51255@www.zefox.net> <078B736E-4807-42C7-B6A5-656F3A50DAEB@dsl-only.net> <20170505230106.GA52464@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 00:44:26 -0000 On 2017-May-5, at 4:01 PM, bob prohaska wrote: > On Fri, May 05, 2017 at 12:38:14PM -0700, Mark Millard wrote: >> >> An rpi2 has Cortex-A7 (armv7-A) cores that have NEON >> but armv6 does not. >> >> There is some possibility that with something like >> -mcpu=cortex-a7 in use as a compiler option that >> NEON would be used. > > What's the simplest way to try it on a self-hosted RPI2 running > -current? At this point I'm just using make -DBATCH in > /usr/ports/www/firefox and following my nose. There's nothing > valuable on the system, it's only for testing. I've never built firefox for anything. The only place I have set up a (fairly minimal) x11 environment is on amd64 virtual machine guests, again no firefox or anything else major, just lumina and xterm (local use, not internet use). So it would be a research project for me to get a special/non-default firefox build done on a rpi2. (There are some fairly general, but not universal, techniques for supplying compiler options to ports. I've no clue were firefox lands for such properties.) >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217611 >> >> (VFP and NEON are related by the registers used.) >> >> So there could be other problems with NEON enabled code >> until it is all resolved. (And head gets the work before >> stable/11 gets the result.) >> > > Most of the discussion in the thread is beyond me, but it > is appreciated that the problem isn't simple. The overall effect: you may get odd results from corrupted NEON register values when NEON is put to use. (I do not know the detailed status of what is working vs. not for NEON/VFP at this point.) === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat May 6 05:01: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 D931FD60FBB; Sat, 6 May 2017 05:01:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B7A461BDC; Sat, 6 May 2017 05:01:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v4651eJR054656 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 May 2017 22:01:41 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v4651eFf054655; Fri, 5 May 2017 22:01:40 -0700 (PDT) (envelope-from fbsd) Date: Fri, 5 May 2017 22:01:40 -0700 From: bob prohaska To: Mark Millard Cc: ports@freebsd.org, freebsd-arm@freebsd.org Subject: Re: RPI2, www/firefox, error: "NEON support not enabled" Message-ID: <20170506050140.GA54543@www.zefox.net> References: <20170505151339.GA51255@www.zefox.net> <962F9C0D-C7C8-4940-A381-B3097FD2A138@dsl-only.net> <20170505182838.GB51255@www.zefox.net> <078B736E-4807-42C7-B6A5-656F3A50DAEB@dsl-only.net> <20170505230106.GA52464@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 05:01:43 -0000 On Fri, May 05, 2017 at 05:44:16PM -0700, Mark Millard wrote: > > (There are some fairly general, but not universal, > techniques for supplying compiler options to ports. > I've no clue were firefox lands for such > properties.) > It appears that using make CFLAGS='-mcpu=cortex-a7' is sufficient to get past the NEON not enabled error. Thanks for your help! bob prohaska From owner-freebsd-arm@freebsd.org Sat May 6 05:13:21 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34CE1D60442 for ; Sat, 6 May 2017 05:13:21 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (kientzle.com [142.254.26.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8274E83 for ; Sat, 6 May 2017 05:13:20 +0000 (UTC) (envelope-from tim@kientzle.com) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id v4657SBI026876; Sat, 6 May 2017 05:07:28 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.101] (192.168.1.101 [192.168.1.101]) by kientzle.com with SMTP id z5mvgnqr6rfftfmjg73pzwgyh6; Sat, 06 May 2017 05:07:28 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: SIGBUS on crochet for rpi3 From: Tim Kientzle In-Reply-To: Date: Fri, 5 May 2017 22:07:28 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <9F969A68-DE25-4AB8-B141-611664AD6607@kientzle.com> References: To: Matt Dube X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 05:13:21 -0000 > On May 4, 2017, at 8:57 AM, Matt Dube wrote: > > Hi, I'm not sure if I'm doing something obviously wrong but I get the > following when I try to build the image for rpi3 with crochet. > --- CodeGen/CGExprScalar.o --- > c++: error: unable to execute command: Bus error (core dumped) > c++: error: clang frontend command failed due to signal (use -v to see > invocation > ) I think I remember seeing this when the build system ran out of memory. Tim