From owner-freebsd-arm@freebsd.org Sun Dec 10 05:49:56 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7BC93E82FB5 for ; Sun, 10 Dec 2017 05:49:56 +0000 (UTC) (envelope-from qroxana@mail.ru) Received: from fallback.mail.ru (fallback8.mail.ru [94.100.181.110]) (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 3212B64981 for ; Sun, 10 Dec 2017 05:49:55 +0000 (UTC) (envelope-from qroxana@mail.ru) Received: from [10.161.64.37] (port=42276 helo=smtp29.i.mail.ru) by fallback8.mail.ru with esmtp (envelope-from ) id 1eNuUk-0005WH-0W for freebsd-arm@freebsd.org; Sun, 10 Dec 2017 08:49:46 +0300 Received: by smtp29.i.mail.ru with esmtpa (envelope-from ) id 1eNuUb-0002XB-3O for freebsd-arm@freebsd.org; Sun, 10 Dec 2017 08:49:38 +0300 Date: Sun, 10 Dec 2017 05:49:22 +0000 From: qroxana To: freebsd-arm@freebsd.org Subject: sun7i-a20-bananapi.dtb not working with ubldr.bin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: X-7FA49CB5: 0D63561A33F958A554416BAE6E88A547F7B38256612911C52CF83556E2A30540725E5C173C3A84C335DD0F8E7B9C57651000CD07F8E150DD42539A7722CA490CB5C8C57E37DE458B4C7702A67D5C3316FA3894348FB808DB3ED5D3630CBC9D05E5BFE6E7EFDEDCD789D4C264860C145E X-Mailru-Sender: 97D519DDE118A67C52373AD59D81B62A361BBB0B0A538F9C11A27FC7BDB2E1998818783B3234F3044B6F39675618FA1517AC0C720661B013D803E13C50B382548DBACFFC59A954823A6964F1EB0AED09430EE79FD2934EACEE82DB220F2CBC970D4ABDE8C577C2ED X-Mras: OK X-Mras: OK X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 05:49:56 -0000 Hi, I just tried to replaced the old ubldr with ubldr.bin, it's running 12.0-CURRENT r326523. Switching back to old ubldr it worked again. Found FreeBSD U-Boot Loader (bin) reading ubldr.bin 237276 bytes read in 34 ms (6.7 MiB/s) ## Starting application at 0x42000000 ... Consoles: U-Boot console Compatible U-Boot API signature found @0x7af36478 FreeBSD/armv7 U-Boot loader, Revision 1.2 (Tue Dec 5 10:31:41 UTC 2017 root@bpi) DRAM: 1024MB MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Number of U-Boot devices: 2 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=0 slice= partition=... good. Booting from disk0s2a: /boot/kernel/kernel text=0x7cfc10 data=0x7c71c+0x182ca4 syms=[0x4+0x94070+0x4+0xd78c4] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/dtb/sun7i-a20-bananapi.dtb size=0xe313 No valid device tree blob found! Thanks, From owner-freebsd-arm@freebsd.org Mon Dec 11 07:17: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 00569E88750 for ; Mon, 11 Dec 2017 07:17:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-128.reflexion.net [208.70.210.128]) (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 B1261750B0 for ; Mon, 11 Dec 2017 07:17:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8834 invoked from network); 11 Dec 2017 07:17:04 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 11 Dec 2017 07:17:04 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 11 Dec 2017 02:17:04 -0500 (EST) Received: (qmail 8918 invoked from network); 11 Dec 2017 07:17:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Dec 2017 07:17:03 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 15A76EC8638 for ; Sun, 10 Dec 2017 23:17:03 -0800 (PST) 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: Manually switching booting a rpi2 via a kernel from a USB SSD (also a sometimes boot hang somewhat after the Release APs notice) Message-Id: Date: Sun, 10 Dec 2017 23:17:02 -0800 To: Freebsd-arm X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 07:17:12 -0000 The mechanism for holding mmcssd0 in the slot failed on the rpi2 V1.1 that I use --but the eject mechanism still works. I've found that the following odd sequence allows me to only need the mmcsd0 temporarily during booting. *) mmcsd0 does need a rpi-firmware, u-boot.bin, for the rpi2, ubldr.bin, and a UFS with a kernel and loader that gets far enough to allow an unload, /boot/loader.conf (as necessary), and an /etc/fstab (more notes below). A) I have /etc/fstab that is on that UFS file system specify the USB SSD root file system as / . (I use a ufs label and /dev/ufs/LABEL specification.) [Historically this is how I had / on the USB SSD so this is not new. I used to have the mmcsd0 have a full root file system that I could boot as well, a form of disaster recovery.] B) Hold the mmcsd0 in the slot during the following, starting from just before powering on. C) During the 10 sec countdown, escape into the loader. D) Let go of mmcsd0: it is not needed until the next reboot. E) unload F) boot kernel It turns out that (F) picks up the kernel and such from the USB SSD instead of from mmcsd0. This sequence should not require mmcsd0 to require most kernel updates but still could someday require some of the following to be updated on mmcsd0: the rpi-firmware, u-boot, ubldr.bin, the loader [file(s)?], /boot/loader.conf, /etc/fstab . Warning: Both before and after this issue I have observed examples of boot hangups somewhat after the Release APs notice. For example. . . . . . Release APs Trying to mount root from ufs:/dev/ufs/RPI2rootfs [rw,noatime]... random: unblocking device. arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache that never seems to time out but just sits there. It allows the ~^B sequence to get to the db> prompt. I've looked around a little a couple of times. Context: head -r326726 based. One common point is that show allchains has everything listed as sleeping except: chain 32: thread 100001 (pid 1, kernel) blocked on sx "umadrain" XLOCK thread 100077 (pid 23, uma) is on a run queue chain 33: (Note: uma's thread number has varied, as has the one for [pagedaemon].) bd> ps pid ppid pgrp uid state wmesg wchan cmd 28 0 0 0 DL syncer 0xc095a31c [syncer] 27 0 0 0 DL vlruwt 0xd7417730 [vnlru] 26 0 0 0 DL psleep 0xc0959c00 [bufdaemon] 25 0 0 0 RL [bufspacedaemon] 24 0 0 0 DL psleep 0xc095e8f8 [vmdaemon] 23 0 0 0 RL (threaded) [pagedaemon] 100065 RunQ [pagedaemon] 100076 D launds 0xc095e804 [laundry: dom0] 100077 RunQ [uma] . . . 1 0 0 0 DL umadrai 0xc095e528 [kernel] 0 0 0 0 RLs (threaded) [kernel] 100000 D swapin 0xc09673c8 [swapper] . . . 100072 D - 0xd75b7e80 [if_io_tqg_1] 100073 RunQ [if_io_tqg_2] 100074 D - 0xd75b7d80 [if_io_tqg_3] 100075 D - 0xd75b7d00 [if_config_tqg_0] 100078 D - 0xd83dc100 [softirq_0] 100079 D - 0xd75b7c00 [softirq_1] 100080 RunQ [softirq_2] 100081 D - 0xd75b7b00 [softirq_3] (Which if_io_tqg_ and softirq_ pair has RunQ varies.) All RunQ's are shown above. One or two [idle: CPU]'s have state CanRun and the other [idle: CPU]'s have state RUN. They are the only items with those states. Example from the same hangup: 10 0 0 0 RL (threaded) [idle] 100002 Run CPU 0 [idle: cpu0] 100003 Run CPU 1 [idle: cpu1] 100004 CanRun [idle: cpu2] 100005 CanRun [idle: cpu3] =20 db> show lock 0xc095e528 class: sx name: umadrain state: XLOCK: 0xd6cbe740 (tid 100077, pid 23, "uma") waiters: shared db> show thread 100001 Thread 100001 at 0xd40a7000: proc (pid 1): 0xd40a3000 name: kernel stack: 0xd40ac000-0xd40adfff flags: 0x4 pflags: 0x20000000 state: INHIBITED: {SLEEPING} wmesg: umadrain wchan: 0xc095e528 sleeptimo 0. 0 (curr 51d. = 5eac6a0400000000) priority: 84 container lock: sleepq chain (0xc0957244) last voluntary switch: 1297717 ms ago last involuntary switch: 1297809 ms ago db> show thread 100077 Thread 100077 at 0xd6cbe740: proc (pid 23): 0xd6cab000 name: uma stack: 0xd83ca000-0xd83cbfff flags: 0x4 pflags: 0x200000 state: RUNQ priority: 84 container lock: sched lock 2 (0xc0952640) last voluntary switch: 1297815 ms ago last involuntary switch: 1297815 ms ago db> show thread 100073 Thread 100073 at 0xd7406740: proc (pid 0): 0xc09673c8 name: if_io_tqg_2 stack: 0xd742a000-0xd742bfff flags: 0x4 pflags: 0x200000 state: RUNQ priority: 24 container lock: sched lock 2 (0xc0952640) last voluntary switch: 1297818 ms ago db> show thread 100080 Thread 100080 at 0xd7431ae0: proc (pid 0): 0xc09673c8 name: softirq_2 stack: 0xd83f5000-0xd83f6fff flags: 0x4 pflags: 0x200000 state: RUNQ priority: 24 container lock: sched lock 2 (0xc0952640) last voluntary switch: 1297816 ms ago db> show lock 0xc0952640 class: spin mutex name: sched lock 2 flags: {SPIN, RECURSE} state: {UNOWNED} db> show lock 0xc0957244 class: spin mutex name: sleepq chain flags: {SPIN, RECURSE} state: {UNOWNED} db> show thread 100065 Thread 100065 at 0xd6cbb000: proc (pid 23): 0xd6cab000 name: pagedaemon stack: 0xd7403000-0xd7404fff flags: 0x14 pflags: 0x20200000 state: RUNQ priority: 84 container lock: sched lock 1 (0xc0951f80) last voluntary switch: 1029 ms ago last involuntary switch: 28606 ms ago db> show lock 0xc0951f80 class: spin mutex name: sched lock 1 flags: {SPIN, RECURSE} state: {UNOWNED} =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Dec 12 07:21: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 AA850E902B5 for ; Tue, 12 Dec 2017 07:21:32 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E4386FEDA; Tue, 12 Dec 2017 07:21:32 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=192.168.25.127; helo=restart.be; envelope-from=hlh@restart.be; receiver=ian@freebsd.org DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3ywrpx4yJPzrJm Received: from restart.be (norquay.tunnel.bel [192.168.25.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3ywrpx4yJPzrJm; Tue, 12 Dec 2017 08:21:29 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [192.168.24.9]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id vBC7LPKY066243 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 12 Dec 2017 08:21:27 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time From: Henri Hennebert To: Ian Lepore , Andreas Schwarz , freebsd-arm@FreeBSD.org References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> <1510851514.99235.378.camel@freebsd.org> <55dd038f-4d82-4fca-bd57-8315bb99c38b@restart.be> Message-ID: Date: Tue, 12 Dec 2017 08:21:25 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <55dd038f-4d82-4fca-bd57-8315bb99c38b@restart.be> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 07:21:32 -0000 On 11/20/2017 13:44, Henri Hennebert wrote: > On 11/16/2017 17:58, Ian Lepore wrote: >> On Tue, 2017-11-14 at 23:03 +0100, Andreas Schwarz wrote: >>> On 14.11.17, Henri Hennebert wrote: >>>> >>>> On 11/13/2017 21:03, Mark Millard wrote: >>>>> >>>>> >>>>> So it looks like you are getting bad times from at >>>>> least 2 servers. Note that the other servers seem >>>>> fine as far as your e-mailed material goes. >>>> I believe that the clock of the Pine64+ is going too fast and that >>>> the 2 >>>> servers where polled and so show this offset/jitter. In an other >>>> occurrence of this problem, if I wait long enough, all servers display >>>> huge offset. >>> But they step not simultaneous to this offset (which is ~300s), why >>> should some >>> servers have such offset and others not?. >>> >> >> Because not all peers are being polled at the same time, and the offset >> and jitter are updated only after a polling cycle.  In the last ntpq: >> >>>>        remote           refid      st t when poll >>>> reach   delay   offset jitter >>>> ============================================================================== >>>> >>>> 0.freebsd.pool. .POOL.          16 >>>> p    -   64    0    0.000    0.000  0.000 >>>> -webhost2.mitht. 193.67.79.202    2 u  948 >>>> 1024  177   58.815    1.451 0.932 >>>> +ns2.telecom.lt  212.59.3.3       2 u   13 >>>> 1024  177   43.400  -357912 357913. >>>> +ntp.bserved.nl  193.67.79.202    2 u 1111 >>>> 1024   37   17.664    0.980 0.379 >>>> -178.32.44.208 ( 193.190.230.65   2 u   81 >>>> 1024  177   14.930    1.087 135278. >>>> *stratum2-1.NTP. 129.70.130.71    2 u 1077 >>>> 1024   77   28.135    1.998 0.570 >>>> -linode.ibendit. 199.102.46.77    2 u 2048 >>>> 1024   76  129.945    0.307 0.584 >>>> #193.104.37.238  193.190.230.66   2 u  799 >>>> 1024   77   14.977    1.321 0.821 >> >> Notice that the two anomalous servers are the ones with a small "when" >> value, indicating they were polled within the last couple minutes. >> >> Also, the fact that some of the "when" values are larger than the >> polling interval is unusual... that would tend to indicate network >> trouble... some of the servers are only beeing reached intermitantly >> (which can be seen by the incomplete "reach" masks). >> >> The idea that two public stratum-2 servers are providing consistant bad >> time is not a viable theory. >> >> Also, the time is good and stable for several of the ten-minute >> intervals, and it was good for long enough that the polling interval >> ramped up from 64 to 1024 seconds (assuming there is no "minpoll" >> override forcing it to 1024 in ntp.conf).  That argues against any kind >> of constant clock-drift problem.  Either the clock is stepping due to a >> problem in the driver such as not handling rollover of a 32-bit >> register, or the clock goes wildly off-frequency, but only >> intermittantly.  The latter might happen if the cpu clock is being used >> as a timecounter and the cpu falls back to a low-power mode that cuts >> the clock frequency in half or something. > > Thank you for those illuminating informations > > I will try another Pine64+ and a new power supply On a new pine64+ (bord + power + usb hub + another usb disk) FreeBSD nakiska.restart.bel 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r325991M: Thu Nov 30 11:56:47 CET 2017 root@nakiska.restart.bel:/usr/obj/usr/src/arm64.aarch64/sys/NORQUAY arm64 Without ntpd running, I observe a drift of 3 minutes after 12 hours during the night with only the periodic jobs running. Henri > > Henri > >> -- Ian >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Tue Dec 12 11:10:44 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9BF0CE946C1 for ; Tue, 12 Dec 2017 11:10:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-96.reflexion.net [208.70.210.96]) (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 5C1D076988 for ; Tue, 12 Dec 2017 11:10:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19359 invoked from network); 12 Dec 2017 11:10:36 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 12 Dec 2017 11:10:36 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 12 Dec 2017 06:10:36 -0500 (EST) Received: (qmail 11924 invoked from network); 12 Dec 2017 11:10:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Dec 2017 11:10:36 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D0258EC8B7B; Tue, 12 Dec 2017 03:10:35 -0800 (PST) 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: A head kernel rpi2 boot-hang bisected: -r326346 good; -r326347 and later hangs-up during boot Message-Id: <32649011-1CFA-4215-BB37-00E4493882CD@dsl-only.net> Date: Tue, 12 Dec 2017 03:10:34 -0800 To: jeff@FreeBSD.org, Freebsd-arm , FreeBSD Hackers , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 11:10:44 -0000 I initially jumped from -r326192 to -r326726 and ended up with a rpi2 that would normally hang somewhere around release APs being displayed. (I have had a couple of completed boots but many dozens of hung-up attempts.) Both a debug kernel and a non-debug kernel hang the same way. Bisecting the kernel (holding world -r326726 constant) showed: -r326346 did not hang (nor did before) -r326347 and later hung. Conclusion: -r326347 changes are involved in the boot hangups. Context: head -r326726 based (from before I did the bisect). My knowledge is limited so I may not have picked optimal material to get from the db> prompt. It appears that the messages about "random" occur during the hang (indefinite wait). As I remember, I have seen examples where the "Trying to mount" did not show up --but normally it did. And example from a hung boot: . . . Release APs Trying to mount root from ufs:/dev/ufs/RPI2rootfs [rw,noatime]... random: unblocking device. arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache The hang never seems to time out but just sits there, even for hours. It allows the ~^B sequence to get to the db> prompt. I've looked around a little a couple of times. One common point is that show allchains has everything listed as sleeping except: chain 32: thread 100001 (pid 1, kernel) blocked on sx "umadrain" XLOCK thread 100077 (pid 23, uma) is on a run queue chain 33: (Note: uma's thread number has varied, as has the one for [pagedaemon].) bd> ps pid ppid pgrp uid state wmesg wchan cmd 28 0 0 0 DL syncer 0xc095a31c [syncer] 27 0 0 0 DL vlruwt 0xd7417730 [vnlru] 26 0 0 0 DL psleep 0xc0959c00 [bufdaemon] 25 0 0 0 RL [bufspacedaemon] 24 0 0 0 DL psleep 0xc095e8f8 [vmdaemon] 23 0 0 0 RL (threaded) [pagedaemon] 100065 RunQ [pagedaemon] 100076 D launds 0xc095e804 [laundry: dom0] 100077 RunQ [uma] . . . 1 0 0 0 DL umadrai 0xc095e528 [kernel] 0 0 0 0 RLs (threaded) [kernel] 100000 D swapin 0xc09673c8 [swapper] . . . 100072 D - 0xd75b7e80 [if_io_tqg_1] 100073 RunQ [if_io_tqg_2] 100074 D - 0xd75b7d80 [if_io_tqg_3] 100075 D - 0xd75b7d00 [if_config_tqg_0] 100078 D - 0xd83dc100 [softirq_0] 100079 D - 0xd75b7c00 [softirq_1] 100080 RunQ [softirq_2] 100081 D - 0xd75b7b00 [softirq_3] (Which if_io_tqg_ and softirq_ pair has RunQ varies.) All RunQ's are shown above. One or two [idle: CPU]'s have state CanRun and the other [idle: CPU]'s have state RUN. They are the only items with those states. Example from the same hangup: 10 0 0 0 RL (threaded) [idle] 100002 Run CPU 0 [idle: cpu0] 100003 Run CPU 1 [idle: cpu1] 100004 CanRun [idle: cpu2] 100005 CanRun [idle: cpu3] db> show lock 0xc095e528 class: sx name: umadrain state: XLOCK: 0xd6cbe740 (tid 100077, pid 23, "uma") waiters: shared db> show thread 100001 Thread 100001 at 0xd40a7000: proc (pid 1): 0xd40a3000 name: kernel stack: 0xd40ac000-0xd40adfff flags: 0x4 pflags: 0x20000000 state: INHIBITED: {SLEEPING} wmesg: umadrain wchan: 0xc095e528 sleeptimo 0. 0 (curr 51d. = 5eac6a0400000000) priority: 84 container lock: sleepq chain (0xc0957244) last voluntary switch: 1297717 ms ago last involuntary switch: 1297809 ms ago db> show thread 100077 Thread 100077 at 0xd6cbe740: proc (pid 23): 0xd6cab000 name: uma stack: 0xd83ca000-0xd83cbfff flags: 0x4 pflags: 0x200000 state: RUNQ priority: 84 container lock: sched lock 2 (0xc0952640) last voluntary switch: 1297815 ms ago last involuntary switch: 1297815 ms ago db> show thread 100073 Thread 100073 at 0xd7406740: proc (pid 0): 0xc09673c8 name: if_io_tqg_2 stack: 0xd742a000-0xd742bfff flags: 0x4 pflags: 0x200000 state: RUNQ priority: 24 container lock: sched lock 2 (0xc0952640) last voluntary switch: 1297818 ms ago db> show thread 100080 Thread 100080 at 0xd7431ae0: proc (pid 0): 0xc09673c8 name: softirq_2 stack: 0xd83f5000-0xd83f6fff flags: 0x4 pflags: 0x200000 state: RUNQ priority: 24 container lock: sched lock 2 (0xc0952640) last voluntary switch: 1297816 ms ago db> show lock 0xc0952640 class: spin mutex name: sched lock 2 flags: {SPIN, RECURSE} state: {UNOWNED} db> show lock 0xc0957244 class: spin mutex name: sleepq chain flags: {SPIN, RECURSE} state: {UNOWNED} db> show thread 100065 Thread 100065 at 0xd6cbb000: proc (pid 23): 0xd6cab000 name: pagedaemon stack: 0xd7403000-0xd7404fff flags: 0x14 pflags: 0x20200000 state: RUNQ priority: 84 container lock: sched lock 1 (0xc0951f80) last voluntary switch: 1029 ms ago last involuntary switch: 28606 ms ago db> show lock 0xc0951f80 class: spin mutex name: sched lock 1 flags: {SPIN, RECURSE} state: {UNOWNED} =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Dec 12 11:47:45 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 106ECE956DC for ; Tue, 12 Dec 2017 11:47:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-169.reflexion.net [208.70.210.169]) (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 C244B7840E for ; Tue, 12 Dec 2017 11:47:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19469 invoked from network); 12 Dec 2017 11:40:22 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 12 Dec 2017 11:40:22 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 12 Dec 2017 06:40:22 -0500 (EST) Received: (qmail 6924 invoked from network); 12 Dec 2017 11:40:22 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Dec 2017 11:40:22 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 074D0EC861A; Tue, 12 Dec 2017 03:40:22 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r326446 kernel and before: an example rpi2 panic: pmap_remove_pages: pmap 0xc3c06??? va 0x202????? pte2 0 panic: bad pte2 (2 examples) Message-Id: Date: Tue, 12 Dec 2017 03:40:21 -0800 To: Freebsd-arm , FreeBSD Hackers X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 11:47:45 -0000 -r326346 is the last kernel version that I can normally boot the rpi2 I use with. So I do not know about later versions. World was at -r326726 as I was bisecting a different issue based on kernel versions after updating had boot problems. I've only seen this type of panic a couple of times during the bisect, once at shutdown before buffers were flushed, once just after login. I've no, known way to reproduce this on demand. If I see it again, I'll try to get more information. I do have back traces from both examples below. Both involve exec_elf32_imgact . . . . Waiting for PIDS: 659pmap_remove_pages: pmap 0xc3c06564 va 0x202df000 pte2 0 panic: bad pte2 cpuid = 1 time = 1513072659 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc0561a88 lr = 0xc005f0d4 (db_trace_self_wrapper+0x30) sp = 0xc365e878 fp = 0xc365e990 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc005f0d4 lr = 0xc026abdc (vpanic+0x158) sp = 0xc365e998 fp = 0xc365e9b8 r4 = 0x00000100 r5 = 0x00000001 r6 = 0xc06e7d7a r7 = 0xc0933530 vpanic() at vpanic+0x158 pc = 0xc026abdc lr = 0xc026ac7c (kproc_shutdown) sp = 0xc365e9c0 fp = 0xc365e9c4 r4 = 0x00000000 r5 = 0x21dfb801 r6 = 0xc1e1e15c r7 = 0x00000001 r8 = 0xc3c06564 r9 = 0xc1e1e000 r10 = 0xc1e1e19c kproc_shutdown() at kproc_shutdown pc = 0xc026ac7c lr = 0xc057aee8 (pmap_remove_pages+0x8e0) sp = 0xc365e9cc fp = 0xc365ea28 r4 = 0xc026ac7c r5 = 0xc365e9cc pmap_remove_pages() at pmap_remove_pages+0x8e0 pc = 0xc057aee8 lr = 0xc022a304 (exec_new_vmspace+0x184) sp = 0xc365ea30 fp = 0xc365ea78 r4 = 0xc3a87f1c r5 = 0xc3a87f00 r6 = 0xc06a5655 r7 = 0xc4502730 r8 = 0xc3c064b0 r9 = 0xc08062c8 r10 = 0xc365ec20 exec_new_vmspace() at exec_new_vmspace+0x184 pc = 0xc022a304 lr = 0xc0207d98 (exec_elf32_imgact+0x86c) sp = 0xc365ea80 fp = 0xc365eb10 r4 = 0xc08062c8 r5 = 0xc09314fc r6 = 0xe695c134 r7 = 0xc0806380 r8 = 0x00000000 r9 = 0xc365ec20 r10 = 0xe695c000 exec_elf32_imgact() at exec_elf32_imgact+0x86c pc = 0xc0207d98 lr = 0xc0228f98 (kern_execve+0x66c) sp = 0xc365eb18 fp = 0xc365ed60 r4 = 0xc365ec20 r5 = 0x00000000 r6 = 0x00000004 r7 = 0x00000000 r8 = 0xc365ed70 r9 = 0xffffffff r10 = 0xc0931ba0 kern_execve() at kern_execve+0x66c pc = 0xc0228f98 lr = 0xc0228604 (sys_execve+0x58) sp = 0xc365ed68 fp = 0xc365edb0 r4 = 0xc4515740 r5 = 0x00000000 r6 = 0xc45159d8 r7 = 0x00000000 r8 = 0x00000000 r9 = 0xc4515740 r10 = 0xc45159d0 sys_execve() at sys_execve+0x58 pc = 0xc0228604 lr = 0xc0584eac (swi_handler+0x2c4) sp = 0xc365edb8 fp = 0xc365ee40 r4 = 0x200b2718 r5 = 0xc08242a4 r6 = 0xc4502730 r10 = 0xc45159d0 swi_handler() at swi_handler+0x2c4 pc = 0xc0584eac lr = 0xc056445c (swi_exit) sp = 0xc365ee48 fp = 0xbfbfdf78 r4 = 0x200b2718 r5 = 0x200b26cc r6 = 0x200b272c r7 = 0x0000003b r8 = 0xbfbfdf80 r9 = 0x200b2718 r10 = 0x00033844 swi_exit() at swi_exit pc = 0xc056445c lr = 0xc056445c (swi_exit) sp = 0xc365ee48 fp = 0xbfbfdf78 KDB: enter: panic [ thread pid 811 tid 100105 ] Stopped at $d.3: ldrb r15, [r15, r15, ror r15]! pmap_remove_pages: pmap 0xc3c060b4 va 0x20208000 pte2 0 panic: bad pte2 cpuid = 0 time = 1513077251 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc0562044 lr = 0xc005f0d4 (db_trace_self_wrapper+0x30) sp = 0xc1d8c878 fp = 0xc1d8c990 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc005f0d4 lr = 0xc026abdc (vpanic+0x158) sp = 0xc1d8c998 fp = 0xc1d8c9b8 r4 = 0x00000100 r5 = 0x00000001 r6 = 0xc06e8468 r7 = 0xc0933530 vpanic() at vpanic+0x158 pc = 0xc026abdc lr = 0xc026ac7c (kproc_shutdown) sp = 0xc1d8c9c0 fp = 0xc1d8c9c4 r4 = 0x00000000 r5 = 0x15f40801 r6 = 0xc1e2d828 r7 = 0x00000001 r8 = 0xc3c060b4 r9 = 0xc1e2d000 r10 = 0xc1e2d868 kproc_shutdown() at kproc_shutdown pc = 0xc026ac7c lr = 0xc057b4a8 (pmap_remove_pages+0x8e0) sp = 0xc1d8c9cc fp = 0xc1d8ca28 r4 = 0xc026ac7c r5 = 0xc1d8c9cc pmap_remove_pages() at pmap_remove_pages+0x8e0 pc = 0xc057b4a8 lr = 0xc022a304 (exec_new_vmspace+0x184) sp = 0xc1d8ca30 fp = 0xc1d8ca78 r4 = 0xc3a87f1c r5 = 0xc3a87f00 r6 = 0xc06a5c55 r7 = 0xc49f2ac8 r8 = 0xc3c06000 r9 = 0xc0806b08 r10 = 0xc1d8cc20 exec_new_vmspace() at exec_new_vmspace+0x184 pc = 0xc022a304 lr = 0xc0207d98 (exec_elf32_imgact+0x86c) sp = 0xc1d8ca80 fp = 0xc1d8cb10 r4 = 0xc0806b08 r5 = 0xc09314fc r6 = 0xe75bc134 r7 = 0xc0806bc0 r8 = 0x00000000 r9 = 0xc1d8cc20 r10 = 0xe75bc000 exec_elf32_imgact() at exec_elf32_imgact+0x86c pc = 0xc0207d98 lr = 0xc0228f98 (kern_execve+0x66c) sp = 0xc1d8cb18 fp = 0xc1d8cd60 r4 = 0xc1d8cc20 r5 = 0x00000000 r6 = 0x00000004 r7 = 0x00000000 r8 = 0xc1d8cd70 r9 = 0xffffffff r10 = 0xc0931ba0 kern_execve() at kern_execve+0x66c pc = 0xc0228f98 lr = 0xc0228604 (sys_execve+0x58) sp = 0xc1d8cd68 fp = 0xc1d8cdb0 r4 = 0xc4994ae0 r5 = 0x00000000 r6 = 0xc4994d78 r7 = 0x00000000 r8 = 0x00000000 r9 = 0xc4994ae0 r10 = 0xc4994d70 sys_execve() at sys_execve+0x58 pc = 0xc0228604 lr = 0xc05854ac (swi_handler+0x2c4) sp = 0xc1d8cdb8 fp = 0xc1d8ce40 r4 = 0x200ef268 r5 = 0xc0824ae4 r6 = 0xc49f2ac8 r10 = 0xc4994d70 swi_handler() at swi_handler+0x2c4 pc = 0xc05854ac lr = 0xc0564a18 (swi_exit) sp = 0xc1d8ce48 fp = 0xbfbfe5d0 r4 = 0x200ef268 r5 = 0x200ef210 r6 = 0x200ef29c r7 = 0x0000003b r8 = 0xbfbfe5d8 r9 = 0x200ef268 r10 = 0x00033844 swi_exit() at swi_exit pc = 0xc0564a18 lr = 0xc0564a18 (swi_exit) sp = 0xc1d8ce48 fp = 0xbfbfe5d0 KDB: enter: panic [ thread pid 712 tid 100152 ] Stopped at $d.3: ldrb r15, [r15, r15, ror r15]! === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Dec 12 21:38: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 F1A11E85AEB for ; Tue, 12 Dec 2017 21:38:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-129.reflexion.net [208.70.210.129]) (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 AFEAE74163 for ; Tue, 12 Dec 2017 21:38:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9782 invoked from network); 12 Dec 2017 21:31:49 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 12 Dec 2017 21:31:49 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 12 Dec 2017 16:31:49 -0500 (EST) Received: (qmail 10322 invoked from network); 12 Dec 2017 21:31:49 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Dec 2017 21:31:49 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 55B69EC8FE9; Tue, 12 Dec 2017 13:31:48 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r326346 (corrected) kernel and before: an example rpi2 panic: pmap_remove_pages: pmap 0xc3c06??? va 0x202????? pte2 0 panic: bad pte2 (2 examples) Date: Tue, 12 Dec 2017 13:31:47 -0800 References: To: Freebsd-arm , FreeBSD Hackers In-Reply-To: Message-Id: <5E7321BA-5745-497A-ABE8-7744C6CA69A7@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 21:38:31 -0000 [Simply a resend with a corrected Subject line.] On 2017-Dec-12, at 3:40 AM, Mark Millard wrote: > -r326346 is the last kernel version that I can > normally boot the rpi2 I use with. So I do not > know about later versions. World was at > -r326726 as I was bisecting a different > issue based on kernel versions after updating > had boot problems. >=20 > I've only seen this type of panic a couple of > times during the bisect, once at shutdown before > buffers were flushed, once just after login. > I've no, known way to reproduce this on demand. >=20 > If I see it again, I'll try to get more > information. I do have back traces from both > examples below. Both involve exec_elf32_imgact . >=20 > . . . > Waiting for PIDS: 659pmap_remove_pages: pmap 0xc3c06564 va 0x202df000 = pte2 0 > panic: bad pte2 > cpuid =3D 1 > time =3D 1513072659 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc =3D 0xc0561a88 lr =3D 0xc005f0d4 = (db_trace_self_wrapper+0x30) > sp =3D 0xc365e878 fp =3D 0xc365e990 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc =3D 0xc005f0d4 lr =3D 0xc026abdc (vpanic+0x158) > sp =3D 0xc365e998 fp =3D 0xc365e9b8 > r4 =3D 0x00000100 r5 =3D 0x00000001 > r6 =3D 0xc06e7d7a r7 =3D 0xc0933530 > vpanic() at vpanic+0x158 > pc =3D 0xc026abdc lr =3D 0xc026ac7c (kproc_shutdown) > sp =3D 0xc365e9c0 fp =3D 0xc365e9c4 > r4 =3D 0x00000000 r5 =3D 0x21dfb801 > r6 =3D 0xc1e1e15c r7 =3D 0x00000001 > r8 =3D 0xc3c06564 r9 =3D 0xc1e1e000 > r10 =3D 0xc1e1e19c > kproc_shutdown() at kproc_shutdown > pc =3D 0xc026ac7c lr =3D 0xc057aee8 (pmap_remove_pages+0x8e0) > sp =3D 0xc365e9cc fp =3D 0xc365ea28 > r4 =3D 0xc026ac7c r5 =3D 0xc365e9cc > pmap_remove_pages() at pmap_remove_pages+0x8e0 > pc =3D 0xc057aee8 lr =3D 0xc022a304 (exec_new_vmspace+0x184) > sp =3D 0xc365ea30 fp =3D 0xc365ea78 > r4 =3D 0xc3a87f1c r5 =3D 0xc3a87f00 > r6 =3D 0xc06a5655 r7 =3D 0xc4502730 > r8 =3D 0xc3c064b0 r9 =3D 0xc08062c8 > r10 =3D 0xc365ec20 > exec_new_vmspace() at exec_new_vmspace+0x184 > pc =3D 0xc022a304 lr =3D 0xc0207d98 (exec_elf32_imgact+0x86c) > sp =3D 0xc365ea80 fp =3D 0xc365eb10 > r4 =3D 0xc08062c8 r5 =3D 0xc09314fc > r6 =3D 0xe695c134 r7 =3D 0xc0806380 > r8 =3D 0x00000000 r9 =3D 0xc365ec20 > r10 =3D 0xe695c000 > exec_elf32_imgact() at exec_elf32_imgact+0x86c > pc =3D 0xc0207d98 lr =3D 0xc0228f98 (kern_execve+0x66c) > sp =3D 0xc365eb18 fp =3D 0xc365ed60 > r4 =3D 0xc365ec20 r5 =3D 0x00000000 > r6 =3D 0x00000004 r7 =3D 0x00000000 > r8 =3D 0xc365ed70 r9 =3D 0xffffffff > r10 =3D 0xc0931ba0 > kern_execve() at kern_execve+0x66c > pc =3D 0xc0228f98 lr =3D 0xc0228604 (sys_execve+0x58) > sp =3D 0xc365ed68 fp =3D 0xc365edb0 > r4 =3D 0xc4515740 r5 =3D 0x00000000 > r6 =3D 0xc45159d8 r7 =3D 0x00000000 > r8 =3D 0x00000000 r9 =3D 0xc4515740 > r10 =3D 0xc45159d0 > sys_execve() at sys_execve+0x58 > pc =3D 0xc0228604 lr =3D 0xc0584eac (swi_handler+0x2c4) > sp =3D 0xc365edb8 fp =3D 0xc365ee40 > r4 =3D 0x200b2718 r5 =3D 0xc08242a4 > r6 =3D 0xc4502730 r10 =3D 0xc45159d0 > swi_handler() at swi_handler+0x2c4 > pc =3D 0xc0584eac lr =3D 0xc056445c (swi_exit) > sp =3D 0xc365ee48 fp =3D 0xbfbfdf78 > r4 =3D 0x200b2718 r5 =3D 0x200b26cc > r6 =3D 0x200b272c r7 =3D 0x0000003b > r8 =3D 0xbfbfdf80 r9 =3D 0x200b2718 > r10 =3D 0x00033844 > swi_exit() at swi_exit > pc =3D 0xc056445c lr =3D 0xc056445c (swi_exit) > sp =3D 0xc365ee48 fp =3D 0xbfbfdf78 > KDB: enter: panic > [ thread pid 811 tid 100105 ] > Stopped at $d.3: ldrb r15, [r15, r15, ror r15]! >=20 > pmap_remove_pages: pmap 0xc3c060b4 va 0x20208000 pte2 0 > panic: bad pte2 > cpuid =3D 0 > time =3D 1513077251 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc =3D 0xc0562044 lr =3D 0xc005f0d4 = (db_trace_self_wrapper+0x30) > sp =3D 0xc1d8c878 fp =3D 0xc1d8c990 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc =3D 0xc005f0d4 lr =3D 0xc026abdc (vpanic+0x158) > sp =3D 0xc1d8c998 fp =3D 0xc1d8c9b8 > r4 =3D 0x00000100 r5 =3D 0x00000001 > r6 =3D 0xc06e8468 r7 =3D 0xc0933530 > vpanic() at vpanic+0x158 > pc =3D 0xc026abdc lr =3D 0xc026ac7c (kproc_shutdown) > sp =3D 0xc1d8c9c0 fp =3D 0xc1d8c9c4 > r4 =3D 0x00000000 r5 =3D 0x15f40801 > r6 =3D 0xc1e2d828 r7 =3D 0x00000001 > r8 =3D 0xc3c060b4 r9 =3D 0xc1e2d000 > r10 =3D 0xc1e2d868 > kproc_shutdown() at kproc_shutdown > pc =3D 0xc026ac7c lr =3D 0xc057b4a8 (pmap_remove_pages+0x8e0) > sp =3D 0xc1d8c9cc fp =3D 0xc1d8ca28 > r4 =3D 0xc026ac7c r5 =3D 0xc1d8c9cc > pmap_remove_pages() at pmap_remove_pages+0x8e0 > pc =3D 0xc057b4a8 lr =3D 0xc022a304 (exec_new_vmspace+0x184) > sp =3D 0xc1d8ca30 fp =3D 0xc1d8ca78 > r4 =3D 0xc3a87f1c r5 =3D 0xc3a87f00 > r6 =3D 0xc06a5c55 r7 =3D 0xc49f2ac8 > r8 =3D 0xc3c06000 r9 =3D 0xc0806b08 > r10 =3D 0xc1d8cc20 > exec_new_vmspace() at exec_new_vmspace+0x184 > pc =3D 0xc022a304 lr =3D 0xc0207d98 (exec_elf32_imgact+0x86c) > sp =3D 0xc1d8ca80 fp =3D 0xc1d8cb10 > r4 =3D 0xc0806b08 r5 =3D 0xc09314fc > r6 =3D 0xe75bc134 r7 =3D 0xc0806bc0 > r8 =3D 0x00000000 r9 =3D 0xc1d8cc20 > r10 =3D 0xe75bc000 > exec_elf32_imgact() at exec_elf32_imgact+0x86c > pc =3D 0xc0207d98 lr =3D 0xc0228f98 (kern_execve+0x66c) > sp =3D 0xc1d8cb18 fp =3D 0xc1d8cd60 > r4 =3D 0xc1d8cc20 r5 =3D 0x00000000 > r6 =3D 0x00000004 r7 =3D 0x00000000 > r8 =3D 0xc1d8cd70 r9 =3D 0xffffffff > r10 =3D 0xc0931ba0 > kern_execve() at kern_execve+0x66c > pc =3D 0xc0228f98 lr =3D 0xc0228604 (sys_execve+0x58) > sp =3D 0xc1d8cd68 fp =3D 0xc1d8cdb0 > r4 =3D 0xc4994ae0 r5 =3D 0x00000000 > r6 =3D 0xc4994d78 r7 =3D 0x00000000 > r8 =3D 0x00000000 r9 =3D 0xc4994ae0 > r10 =3D 0xc4994d70 > sys_execve() at sys_execve+0x58 > pc =3D 0xc0228604 lr =3D 0xc05854ac (swi_handler+0x2c4) > sp =3D 0xc1d8cdb8 fp =3D 0xc1d8ce40 > r4 =3D 0x200ef268 r5 =3D 0xc0824ae4 > r6 =3D 0xc49f2ac8 r10 =3D 0xc4994d70 > swi_handler() at swi_handler+0x2c4 > pc =3D 0xc05854ac lr =3D 0xc0564a18 (swi_exit) > sp =3D 0xc1d8ce48 fp =3D 0xbfbfe5d0 > r4 =3D 0x200ef268 r5 =3D 0x200ef210 > r6 =3D 0x200ef29c r7 =3D 0x0000003b > r8 =3D 0xbfbfe5d8 r9 =3D 0x200ef268 > r10 =3D 0x00033844 > swi_exit() at swi_exit > pc =3D 0xc0564a18 lr =3D 0xc0564a18 (swi_exit) > sp =3D 0xc1d8ce48 fp =3D 0xbfbfe5d0 > KDB: enter: panic > [ thread pid 712 tid 100152 ] > Stopped at $d.3: ldrb r15, [r15, r15, ror r15]! =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Dec 12 22:03:20 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 AB0F7E868BF; Tue, 12 Dec 2017 22:03:20 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from onager.schwarzes.net (onager.schwarzes.net [IPv6:2a03:4000:8:2bb::5d22]) (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 4EE08753D8; Tue, 12 Dec 2017 22:03:19 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [172.30.250.35] (x4dba65d2.dyn.telefonica.de [77.186.101.210]) (authenticated bits=0) by onager.schwarzes.net (8.15.2/8.15.2) with ESMTPA id vBCM2iHt062687; Tue, 12 Dec 2017 23:02:44 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: Mark Millard CC: jeff@FreeBSD.org, Freebsd-arm , FreeBSD Hackers , FreeBSD Current Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Tue, 12 Dec 2017 23:02:44 +0100 (CET) Message-ID: <4b2420e8899.5992ee2b@mail.schwarzes.net> In-Reply-To: <32649011-1CFA-4215-BB37-00E4493882CD@dsl-only.net> References: <32649011-1CFA-4215-BB37-00E4493882CD@dsl-only.net> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: A head kernel rpi2 boot-hang bisected: -r326346 good; -r326347 and later hangs-up during boot MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (onager.schwarzes.net [37.221.194.76]); Tue, 12 Dec 2017 23:02:45 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 22:03:20 -0000 On 12.12.17, Mark Millard wrote: > I initially jumped from -r326192 to -r326726 and > ended up with a rpi2 that would normally hang > somewhere around release APs being displayed. > (I have had a couple of completed boots but many > dozens of hung-up attempts.) Both a debug kernel > and a non-debug kernel hang the same way. > > Bisecting the kernel (holding world -r326726 > constant) showed: > > -r326346 did not hang (nor did before) > -r326347 and later hung. JFYI, the latest kernel (and world) running at one of my RPI2-B is r326631, without any issues. -asc From owner-freebsd-arm@freebsd.org Tue Dec 12 23:19: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 6789EE88636 for ; Tue, 12 Dec 2017 23:19:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-160.reflexion.net [208.70.210.160]) (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 1322677C13 for ; Tue, 12 Dec 2017 23:19:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26457 invoked from network); 12 Dec 2017 23:19:24 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 12 Dec 2017 23:19:24 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 12 Dec 2017 18:19:24 -0500 (EST) Received: (qmail 9279 invoked from network); 12 Dec 2017 23:19:24 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Dec 2017 23:19:24 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 14E6FEC814E; Tue, 12 Dec 2017 15:19:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A head kernel rpi2 boot-hang bisected: -r326346 good; -r326347 and later hangs-up during boot From: Mark Millard In-Reply-To: <4b2420e8899.5992ee2b@mail.schwarzes.net> Date: Tue, 12 Dec 2017 15:19:23 -0800 Cc: jeff@FreeBSD.org, Freebsd-arm , FreeBSD Hackers , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <241F43AF-23B2-4C54-9B77-A5A7CE3F8E57@dsl-only.net> References: <32649011-1CFA-4215-BB37-00E4493882CD@dsl-only.net> <4b2420e8899.5992ee2b@mail.schwarzes.net> To: Andreas Schwarz X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 23:19:27 -0000 On 2017-Dec-12, at 2:02 PM, Andreas Schwarz = wrote: > On 12.12.17, Mark Millard wrote: >=20 >> I initially jumped from -r326192 to -r326726 and >> ended up with a rpi2 that would normally hang >> somewhere around release APs being displayed. >> (I have had a couple of completed boots but many >> dozens of hung-up attempts.) Both a debug kernel >> and a non-debug kernel hang the same way. >>=20 >> Bisecting the kernel (holding world -r326726 >> constant) showed: >>=20 >> -r326346 did not hang (nor did before) >> -r326347 and later hung. >=20 > JFYI, the latest kernel (and world) running at one of my=20 > RPI2-B is r326631, without any issues. Interesting. (By the way: My context is with a V1.1 Cortex-A7 based rpi2, not V1.2 and Cortex-A53.) I've almost always run the root file system being on a USB SSD instead of on mmcsd0 . I wonder if that is somehow involved since it may be unusual. UFS file system. The USB SSD is on a powered hub that is in turn plugged into the rpi2. [I had the hang problem before the following and after.] The mechanism for holding mmcsd0 in failed recently but the ejection mechanism still works. So I hold in mmcsd0 until after I get a USB SSD boot now. (Interrupt boot, unload, boot/autoboot, picks up the kernel from the USB SSD.) This means that I effectively can not avoid the USB SSD any more unless I get my hands on a different V1.1 rpi2. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Dec 13 00:20: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 71767E8A9AF; Wed, 13 Dec 2017 00:20:08 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from onager.schwarzes.net (onager.schwarzes.net [IPv6:2a03:4000:8:2bb::5d22]) (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 B00867A1EB; Wed, 13 Dec 2017 00:20:07 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [172.30.250.35] (x4dba65d2.dyn.telefonica.de [77.186.101.210]) (authenticated bits=0) by onager.schwarzes.net (8.15.2/8.15.2) with ESMTPA id vBD0K2mT063453; Wed, 13 Dec 2017 01:20:02 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: Mark Millard CC: jeff@FreeBSD.org, Freebsd-arm , FreeBSD Hackers , FreeBSD Current Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Wed, 13 Dec 2017 01:20:01 +0100 (CET) Message-ID: <4b24414033.695511f0@mail.schwarzes.net> In-Reply-To: <241F43AF-23B2-4C54-9B77-A5A7CE3F8E57@dsl-only.net> References: <32649011-1CFA-4215-BB37-00E4493882CD@dsl-only.net> <4b2420e8899.5992ee2b@mail.schwarzes.net> <241F43AF-23B2-4C54-9B77-A5A7CE3F8E57@dsl-only.net> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: A head kernel rpi2 boot-hang bisected: -r326346 good; -r326347 and later hangs-up during boot MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (onager.schwarzes.net [37.221.194.76]); Wed, 13 Dec 2017 01:20:02 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 00:20:08 -0000 On 12.12.17, Mark Millard wrote: > On 2017-Dec-12, at 2:02 PM, Andreas Schwarz wrote: >> JFYI, the latest kernel (and world) running at one of my >> RPI2-B is r326631, without any issues. > > Interesting. (By the way: My context > is with a V1.1 Cortex-A7 based rpi2, > not V1.2 and Cortex-A53.) Same here. The RPI2-B (not V1.2) is the most stable system of all my SBCs running FreeBSD. > I've almost always run the root file > system being on a USB SSD instead of > on mmcsd0 . I wonder if that is > somehow involved since it may be > unusual. UFS file system. > > The USB SSD is on a powered hub that > is in turn plugged into the rpi2. Ok, I don't use an USB HDD, the limited USB bridge is the weakest point at the whole rpi, so there are probably not much users with this setup. I understand that you are forced to use ist -asc From owner-freebsd-arm@freebsd.org Wed Dec 13 00:47:13 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 A07F0E8B6CB for ; Wed, 13 Dec 2017 00:47:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-151.reflexion.net [208.70.210.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4E7737B020 for ; Wed, 13 Dec 2017 00:47:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15100 invoked from network); 13 Dec 2017 00:20:31 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 13 Dec 2017 00:20:31 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 12 Dec 2017 19:20:31 -0500 (EST) Received: (qmail 13273 invoked from network); 13 Dec 2017 00:20:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Dec 2017 00:20:31 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 30083EC814E; Tue, 12 Dec 2017 16:20:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A head kernel rpi2 boot-hang bisected: -r326346 good; -r326347 and later hangs-up during boot From: Mark Millard In-Reply-To: <241F43AF-23B2-4C54-9B77-A5A7CE3F8E57@dsl-only.net> Date: Tue, 12 Dec 2017 16:20:29 -0800 Cc: FreeBSD Hackers , FreeBSD Current , Freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <32649011-1CFA-4215-BB37-00E4493882CD@dsl-only.net> <4b2420e8899.5992ee2b@mail.schwarzes.net> <241F43AF-23B2-4C54-9B77-A5A7CE3F8E57@dsl-only.net> To: Andreas Schwarz , jeff@FreeBSD.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 00:47:13 -0000 On 2017-Dec-12, at 3:19 PM, Mark Millard wrote: > On 2017-Dec-12, at 2:02 PM, Andreas Schwarz wrote: >=20 >> On 12.12.17, Mark Millard wrote: >>=20 >>> I initially jumped from -r326192 to -r326726 and >>> ended up with a rpi2 that would normally hang >>> somewhere around release APs being displayed. >>> (I have had a couple of completed boots but many >>> dozens of hung-up attempts.) Both a debug kernel >>> and a non-debug kernel hang the same way. >>>=20 >>> Bisecting the kernel (holding world -r326726 >>> constant) showed: >>>=20 >>> -r326346 did not hang (nor did before) >>> -r326347 and later hung. >>=20 >> JFYI, the latest kernel (and world) running at one of my=20 >> RPI2-B is r326631, without any issues. >=20 > Interesting. (By the way: My context > is with a V1.1 Cortex-A7 based rpi2, > not V1.2 and Cortex-A53.) >=20 > I've almost always run the root file > system being on a USB SSD instead of > on mmcsd0 . I wonder if that is > somehow involved since it may be > unusual. UFS file system. >=20 > The USB SSD is on a powered hub that > is in turn plugged into the rpi2. >=20 > [I had the hang problem before the > following and after.] >=20 > The mechanism for holding mmcsd0 in > failed recently but the ejection > mechanism still works. So I hold > in mmcsd0 until after I get a USB > SSD boot now. (Interrupt boot, unload, > boot/autoboot, picks up the kernel > from the USB SSD.) >=20 > This means that I effectively can > not avoid the USB SSD any more > unless I get my hands on a different > V1.1 rpi2. Looks like I'll get my hands on a different rpi2 V1.1 in a few days. So I should then be able to do reasonable mmcsd0-only experiments. At least once I find the time. FYI, in case boot details are involved in reproducing the problem. . . On the mmcsd0 I have /boot/loader.conf with: kern.cam.boot_delay=3D"10000" vfs.mountroot.timeout=3D"10" and /etc/fstab with: /dev/ufs/RPI2rootfs / ufs rw,noatime 1 1 /dev/label/RPI2Aswap none swap sw 0 0 /dev/label/RPI2Aboot /boot/msdos msdosfs rw,noatime 0 0 where the /dev/ufs/RPI2rootfs was the USB SSD. However, I interrupt the loader and unload and then boot or autoboot. (But the hangs started before this extra sequence was involved.) On the USB SSD I have /boot/loader.conf with: kern.cam.boot_delay=3D"10000" vfs.mountroot.timeout=3D"10" and /etc/fstab with: /dev/da0p1 / ufs rw,noatime 1 1 /dev/da0p2 none swap sw 0 0 What db> showed does point to things that -r326347 involve: chain 32: thread 100001 (pid 1, kernel) blocked on sx "umadrain" XLOCK thread 100077 (pid 23, uma) is on a run queue But for all I know -r326347 could be depending on something required to be true but not correct elsewhere in the rpi2 support. I'm not claiming that -r326347 is wrong, just that it is involved. I've way to little knowledge to claim to know what is wrong on the evidence that I have. I've not yet tried a bpi-m3 Cortex-A7 context or a pine64+ 2GB or rpi3 Cortex-A53 context. Nor powerpc64 nor powerpc. At some point I'll get the time for one or more of these. I've not had amd64 problems in this area. I may not be able to test the bpi-m3: its barrel connector for power seems flaky and it is difficult to keep the board powered for long periods in recent times. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Dec 13 01:46: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 43876E8CBE9 for ; Wed, 13 Dec 2017 01:46:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-170.reflexion.net [208.70.210.170]) (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 055A57CAA9 for ; Wed, 13 Dec 2017 01:46:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27628 invoked from network); 13 Dec 2017 01:46:00 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 Dec 2017 01:46:00 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 12 Dec 2017 20:46:00 -0500 (EST) Received: (qmail 1238 invoked from network); 13 Dec 2017 01:46:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Dec 2017 01:46:00 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CD280EC86EF; Tue, 12 Dec 2017 17:45:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A head kernel rpi2 boot-hang bisected: -r326346 good; -r326347 and later hangs-up during boot [backtraces added] From: Mark Millard In-Reply-To: Date: Tue, 12 Dec 2017 17:45:59 -0800 Cc: FreeBSD Hackers , Freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <21626363-B6F9-44CE-82C2-91BF0A9F5E4F@dsl-only.net> References: <32649011-1CFA-4215-BB37-00E4493882CD@dsl-only.net> <4b2420e8899.5992ee2b@mail.schwarzes.net> <241F43AF-23B2-4C54-9B77-A5A7CE3F8E57@dsl-only.net> To: jeff@FreeBSD.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 01:46:07 -0000 [Just adding back traces. ffs_mount use of uma_zcreate is involved in the kernel thread, as is uma_reclaim_worker's use of uma_reclaim_locked in the uma thread.] On 2017-Dec-12, at 4:20 PM, Mark Millard wrote: > On 2017-Dec-12, at 3:19 PM, Mark Millard = wrote: >=20 >> On 2017-Dec-12, at 2:02 PM, Andreas Schwarz wrote: >>=20 >>> On 12.12.17, Mark Millard wrote: >>>=20 >>>> I initially jumped from -r326192 to -r326726 and >>>> ended up with a rpi2 that would normally hang >>>> somewhere around release APs being displayed. >>>> (I have had a couple of completed boots but many >>>> dozens of hung-up attempts.) Both a debug kernel >>>> and a non-debug kernel hang the same way. >>>>=20 >>>> Bisecting the kernel (holding world -r326726 >>>> constant) showed: >>>>=20 >>>> -r326346 did not hang (nor did before) >>>> -r326347 and later hung. >>>=20 >>> JFYI, the latest kernel (and world) running at one of my=20 >>> RPI2-B is r326631, without any issues. >>=20 >> Interesting. (By the way: My context >> is with a V1.1 Cortex-A7 based rpi2, >> not V1.2 and Cortex-A53.) >>=20 >> I've almost always run the root file >> system being on a USB SSD instead of >> on mmcsd0 . I wonder if that is >> somehow involved since it may be >> unusual. UFS file system. >>=20 >> The USB SSD is on a powered hub that >> is in turn plugged into the rpi2. >>=20 >> [I had the hang problem before the >> following and after.] >>=20 >> The mechanism for holding mmcsd0 in >> failed recently but the ejection >> mechanism still works. So I hold >> in mmcsd0 until after I get a USB >> SSD boot now. (Interrupt boot, unload, >> boot/autoboot, picks up the kernel >> from the USB SSD.) >>=20 >> This means that I effectively can >> not avoid the USB SSD any more >> unless I get my hands on a different >> V1.1 rpi2. >=20 > Looks like I'll get my hands on a different > rpi2 V1.1 in a few days. So I should then > be able to do reasonable mmcsd0-only > experiments. At least once I find the time. >=20 > FYI, in case boot details are involved > in reproducing the problem. . . >=20 > On the mmcsd0 I have /boot/loader.conf with: >=20 > kern.cam.boot_delay=3D"10000" > vfs.mountroot.timeout=3D"10" >=20 > and /etc/fstab with: >=20 > /dev/ufs/RPI2rootfs / ufs rw,noatime 1 1 > /dev/label/RPI2Aswap none swap sw 0 0 > /dev/label/RPI2Aboot /boot/msdos msdosfs rw,noatime 0 0 >=20 > where the /dev/ufs/RPI2rootfs was the USB SSD. >=20 > However, I interrupt the loader and unload and > then boot or autoboot. (But the hangs started > before this extra sequence was involved.) >=20 > On the USB SSD I have /boot/loader.conf with: >=20 > kern.cam.boot_delay=3D"10000" > vfs.mountroot.timeout=3D"10" >=20 > and /etc/fstab with: >=20 > /dev/da0p1 / ufs rw,noatime 1 1 > /dev/da0p2 none swap sw 0 0 >=20 >=20 > What db> showed does point to things that > -r326347 involve: >=20 > chain 32: > thread 100001 (pid 1, kernel) blocked on sx "umadrain" XLOCK > thread 100077 (pid 23, uma) is on a run queue >=20 > But for all I know -r326347 could be depending > on something required to be true but not correct > elsewhere in the rpi2 support. I'm not claiming > that -r326347 is wrong, just that it is involved. > I've way to little knowledge to claim to know > what is wrong on the evidence that I have. >=20 > I've not yet tried a bpi-m3 Cortex-A7 context or > a pine64+ 2GB or rpi3 Cortex-A53 context. Nor > powerpc64 nor powerpc. At some point I'll get the > time for one or more of these. I've not had amd64 > problems in this area. >=20 > I may not be able to test the bpi-m3: its barrel > connector for power seems flaky and it is > difficult to keep the board powered for long > periods in recent times. For this new example -r326347 kernel based boot-hang: chain 35: thread 100001 (pid 1, kernel) blocked on sx "umadrain" XLOCK thread 100073 (pid 23, uma) is on a run queue db> bt Tracing pid 1 tid 100001 td 0xd429f000 cpu_switch() at cpu_switch+0x18 pc =3D 0xc0584f80 lr =3D 0xc0299ad8 (sched_switch+0x5c0) sp =3D 0xd42a56b8 fp =3D 0xd42a56e8 sched_switch() at sched_switch+0x5c0 pc =3D 0xc0299ad8 lr =3D 0xc0275f28 (mi_switch+0x258) sp =3D 0xd42a56f0 fp =3D 0xd42a5718 r4 =3D 0x0001f0f5 r5 =3D 0x00000000 r6 =3D 0xd429f000 r7 =3D 0x0006612d r8 =3D 0x00000000 r9 =3D 0x00000104 r10 =3D 0xc08073f0 mi_switch() at mi_switch+0x258 pc =3D 0xc0275f28 lr =3D 0xc02c1508 (sleepq_switch+0x1c0) sp =3D 0xd42a5720 fp =3D 0xd42a5748 r4 =3D 0xd429f000 r5 =3D 0xc0947dc4 r6 =3D 0xc09a9c68 r7 =3D 0xc0947dc0 r8 =3D 0x00000000 r9 =3D 0xc09440c0 r10 =3D 0x000000f4 sleepq_switch() at sleepq_switch+0x1c0 pc =3D 0xc02c1508 lr =3D 0xc02c1308 (sleepq_wait+0x48) sp =3D 0xd42a5750 fp =3D 0xd42a5760 r4 =3D 0xd429f000 r5 =3D 0x00000000 r6 =3D 0xc09a9c68 r7 =3D 0xc06b415c r8 =3D 0x00000001 r9 =3D 0xc09a9c78 r10 =3D 0x00000000 sleepq_wait() at sleepq_wait+0x48 pc =3D 0xc02c1308 lr =3D 0xc02748b0 (_sx_slock_hard+0x298) sp =3D 0xd42a5768 fp =3D 0xd42a57c8 r4 =3D 0xc09a9c68 r5 =3D 0xc0823ac0 r6 =3D 0xc06ae146 r7 =3D 0x00000000 _sx_slock_hard() at _sx_slock_hard+0x298 pc =3D 0xc02748b0 lr =3D 0xc027457c (_sx_slock_int+0x140) sp =3D 0xd42a57d0 fp =3D 0xd42a57f8 r4 =3D 0x00000078 r5 =3D 0x00000765 r6 =3D 0xc09a9c68 r7 =3D 0x00000765 r8 =3D 0xc09a9c78 r9 =3D 0xd7ad8740 r10 =3D 0x00000000 _sx_slock_int() at _sx_slock_int+0x140 pc =3D 0xc027457c lr =3D 0xc052b024 (uma_zcreate+0x10c) sp =3D 0xd42a5800 fp =3D 0xd42a5850 r4 =3D 0x00000078 r5 =3D 0xc09a9c68 r6 =3D 0xc06df86e r7 =3D 0xc06dd153 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 uma_zcreate() at uma_zcreate+0x10c pc =3D 0xc052b024 lr =3D 0xc050cc90 (ffs_mount+0x80) sp =3D 0xd42a5858 fp =3D 0xd42a5980 r4 =3D 0xd7844000 r5 =3D 0x00000000 r6 =3D 0x00000003 r7 =3D 0xc09a99c0 r8 =3D 0x00000000 r9 =3D 0xd429f000 r10 =3D 0xd828c400 ffs_mount() at ffs_mount+0x80 pc =3D 0xc050cc90 lr =3D 0xc032e1d4 (vfs_donmount+0xeec) sp =3D 0xd42a5988 fp =3D 0xd42a5b38 r4 =3D 0xffffffff r5 =3D 0xd74ec120 r6 =3D 0xd429f000 r7 =3D 0x00000000 r8 =3D 0x00000000 r9 =3D 0xc425acd0 r10 =3D 0xd828c400 vfs_donmount() at vfs_donmount+0xeec pc =3D 0xc032e1d4 lr =3D 0xc0330ea8 (kernel_mount+0x70) sp =3D 0xd42a5b40 fp =3D 0xd42a5b78 r4 =3D 0xd82a9000 r5 =3D 0x00000000 r6 =3D 0x00004000 r7 =3D 0x00000000 r8 =3D 0xd87e2050 r9 =3D 0xd87e2040 r10 =3D 0x00000000 kernel_mount() at kernel_mount+0x70 pc =3D 0xc0330ea8 lr =3D 0xc03335dc (parse_mount+0x458) sp =3D 0xd42a5b80 fp =3D 0xd42a5c60 r4 =3D 0xd4263500 r5 =3D 0xd87e2054 r6 =3D 0xd82a9000 r7 =3D 0x00000000 parse_mount() at parse_mount+0x458 pc =3D 0xc03335dc lr =3D 0xc0331a44 ($a.2+0x28) sp =3D 0xd42a5c68 fp =3D 0xd42a5dc8 r4 =3D 0xd7845018 r5 =3D 0x00000000 r6 =3D 0xd7845018 r7 =3D 0xd78404da r8 =3D 0xc06bfbd4 r9 =3D 0xfffffff7 r10 =3D 0xd7836380 $a.2() at $a.2+0x28 pc =3D 0xc0331a44 lr =3D 0xc020a82c (start_init+0x5c) sp =3D 0xd42a5dd0 fp =3D 0xd42a5e20 r4 =3D 0xc06a370c r5 =3D 0xc0823ad0 r6 =3D 0x00000000 r7 =3D 0x00000000 r8 =3D 0xd42a5e48 r9 =3D 0x00000000 r10 =3D 0xd429b000 start_init() at start_init+0x5c pc =3D 0xc020a82c lr =3D 0xc0230f10 (fork_exit+0xa0) sp =3D 0xd42a5e28 fp =3D 0xd42a5e40 r4 =3D 0xd429f000 r5 =3D 0xd429b000 r6 =3D 0xc020a7d0 r7 =3D 0x00000000 r8 =3D 0xd42a5e48 r9 =3D 0x00000000 r10 =3D 0x00000000 fork_exit() at fork_exit+0xa0 pc =3D 0xc0230f10 lr =3D 0xc0564c8c (swi_exit) sp =3D 0xd42a5e48 fp =3D 0x00000000 r4 =3D 0xc020a7d0 r5 =3D 0x00000000 r6 =3D 0x00000000 r7 =3D 0x00000000 r8 =3D 0x00000000 r10 =3D 0x00000000 swi_exit() at swi_exit pc =3D 0xc0564c8c lr =3D 0xc0564c8c (swi_exit) sp =3D 0xd42a5e48 fp =3D 0x00000000 db> bt Tracing pid 23 tid 100073 td 0xd7ad8740 cpu_switch() at cpu_switch+0x18 pc =3D 0xc0584f80 lr =3D 0xc0299ad8 (sched_switch+0x5c0) sp =3D 0xd87dad58 fp =3D 0xd87dad88 sched_switch() at sched_switch+0x5c0 pc =3D 0xc0299ad8 lr =3D 0xc0275f28 (mi_switch+0x258) sp =3D 0xd87dad90 fp =3D 0xd87dadb8 r4 =3D 0x00000025 r5 =3D 0x00000000 r6 =3D 0xd7ad8740 r7 =3D 0x000240ea r8 =3D 0x00000000 r9 =3D 0x00000100 r10 =3D 0xc08073f0 mi_switch() at mi_switch+0x258 pc =3D 0xc0275f28 lr =3D 0xc052d9f8 (uma_reclaim_locked+0x200) sp =3D 0xd87dadc0 fp =3D 0xd87dade8 r4 =3D 0x00000003 r5 =3D 0xc08073f0 r6 =3D 0xc08073f0 r7 =3D 0x00000000 r8 =3D 0x00000000 r9 =3D 0xc0824310 r10 =3D 0xc06df86e uma_reclaim_locked() at uma_reclaim_locked+0x200 pc =3D 0xc052d9f8 lr =3D 0xc052de70 (uma_reclaim_worker+0x4c) sp =3D 0xd87dadf0 fp =3D 0xd87dae20 r4 =3D 0xc09a9c68 r5 =3D 0xc4242d80 r6 =3D 0xc06df86e r7 =3D 0x00000000 r8 =3D 0x00000100 r9 =3D 0xc09b3d08 r10 =3D 0xc09a9c7c uma_reclaim_worker() at uma_reclaim_worker+0x4c pc =3D 0xc052de70 lr =3D 0xc0230f10 (fork_exit+0xa0) sp =3D 0xd87dae28 fp =3D 0xd87dae40 r4 =3D 0xd7ad8740 r5 =3D 0xd70ce000 r6 =3D 0xc052de24 r7 =3D 0x00000000 r8 =3D 0xd87dae48 r9 =3D 0xd7ada3a0 r10 =3D 0xc0824e8c fork_exit() at fork_exit+0xa0 pc =3D 0xc0230f10 lr =3D 0xc0564c8c (swi_exit) sp =3D 0xd87dae48 fp =3D 0x00000000 r4 =3D 0xc052de24 r5 =3D 0x00000000 r6 =3D 0x7ff6d83f r7 =3D 0xd6f583a0 r8 =3D 0xc0824dcc r10 =3D 0xc0824e8c swi_exit() at swi_exit pc =3D 0xc0564c8c lr =3D 0xc0564c8c (swi_exit) sp =3D 0xd87dae48 fp =3D 0x00000000 db> show thread 100001 Thread 100001 at 0xd429f000: proc (pid 1): 0xd429b000 name: kernel stack: 0xd42a4000-0xd42a5fff flags: 0x4 pflags: 0x20000000 state: INHIBITED: {SLEEPING} wmesg: umadrain wchan: 0xc09a9c68 sleeptimo 0. 0 (curr 26. = e3fd787f00000000) priority: 84 container lock: sleepq chain (0xc0947dc4) last voluntary switch: 26523 ms ago last involuntary switch: 26695 ms ago db> show thread 100073 Thread 100073 at 0xd7ad8740: proc (pid 23): 0xd70ce000 name: uma stack: 0xd87d9000-0xd87dafff flags: 0x4 pflags: 0x200000 state: RUNQ priority: 84 container lock: sched lock 3 (0xc0942ec0) last voluntary switch: 26694 ms ago db> show lock 0xc0942ec0 class: spin mutex name: sched lock 3 flags: {SPIN, RECURSE} state: {UNOWNED} =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Dec 14 01:34: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 A4402E8E349 for ; Thu, 14 Dec 2017 01:34:26 +0000 (UTC) (envelope-from sm@ara-ler.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 719C66C413 for ; Thu, 14 Dec 2017 01:34:26 +0000 (UTC) (envelope-from sm@ara-ler.com) Received: by mail-it0-x22e.google.com with SMTP id f143so7381623itb.0 for ; Wed, 13 Dec 2017 17:34:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ara-ler-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=YMVKoDa0ab9I5pVj1uF589nvdWEGDFero/COl317m/U=; b=qfMUchcxo+unpJnvpfoEoDhHDhXoj0k0WU/zvLMsL2gUD34bpos0hQ1NrncxFz5Fv7 Ykuts7LuAaRX7sf32PWJbNQnsBBSmFWsJzd2uRn9A/ixglWNw7aedBwCd6reWfVlKv2R lSL39VCYqcNPQkMcNV5muQIqUIiUehq5sPiDs7cLRvZYysrTV5IqIAqOwfkV3uvs+kcI Gtro/MG9BTXOfb7pAOu4y4Fkdh+uAqjU//Z8qpilS2NcjFyOSeym1H6dKz5XcnqdYzUj uc87Gp4NUiptT38Z+eDP/0kCyJWQycHmRoHK3TdLgLvj5GUxR6/QTfDqjxcyi3yPFHfP f3JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=YMVKoDa0ab9I5pVj1uF589nvdWEGDFero/COl317m/U=; b=T72EVw5okZzzlxNBCEMQggzB9vD6qEoU8vxO8ePM9bxVUKTt8PjTlfQAs1xpSXxHVk DQ+h66dCxl4KjqBcSPXlRDaSq3c7lfIQGrzebZS9TmmXwScuYyOG0pBSqLrEbvOfd7uV M8KNWwnpCFzlHgwsdSANBl9wjv1na39PzDl5VHeAUWnrxfsI2TiD65SWFaxQ7Jf0PFiv +ojjLlUJa8xWzhflGoYaqpnujw+oFTGOj8mBr2Zy4kUIuXy3gYrq06oaqy3mzfkjY1yi H0KwpHz7xja5wpWL7Uxc7sJeVAnvo7zAotDoTYNRAApZgTA8ol8bl/o4Ov39uwh5PTx9 FJIQ== X-Gm-Message-State: AKGB3mKpLkbdKT6C0bY+vMUnGx9s/r7x9U5v8FgwfaLl64v68OPfdz/k Gb2bQqBYoJf7+1L1pQufr/87iawl X-Google-Smtp-Source: ACJfBotGuR5HTFYStKjcKJxzTn1dvxa8UTLHU0W/ln9xlsqs7cXZ3n9YKxMz+Lgz4g6A0lr+6rPqKg== X-Received: by 10.107.147.214 with SMTP id v205mr5281655iod.25.1513215265612; Wed, 13 Dec 2017 17:34:25 -0800 (PST) Received: from dendrobates.araler.com (c-67-172-158-8.hsd1.co.comcast.net. [67.172.158.8]) by smtp.gmail.com with ESMTPSA id d128sm1459562iod.35.2017.12.13.17.34.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 17:34:24 -0800 (PST) Date: Wed, 13 Dec 2017 18:34:22 -0700 From: Sergey Manucharian To: freebsd-arm@freebsd.org Subject: BeagleBone Black: boot =?iso-8859-1?Q?from?= =?iso-8859-1?Q?_eMMC=3A_=ABCard_did_not_respond_to_voltage_select=BB?= Message-ID: <20171214013422.GK76632@dendrobates.araler.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 01:34:26 -0000 Does anybody know why when I run FreeBSD 11.1 or 12.0 form eMMC I get several hundreds of lines: Card did not respond to voltage select! Eventually FreeBSD boots and works properly. The same BBB boots fine from an SD card. I'm using "official" images. Those warnings start right after u-boot jumps to ubldr.bin address. They are not harmful, just annoying. Thanks for advises, Sergey From owner-freebsd-arm@freebsd.org Thu Dec 14 08:34:15 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05620E9C5A4 for ; Thu, 14 Dec 2017 08:34:15 +0000 (UTC) (envelope-from qroxana@mail.ru) Received: from fallback.mail.ru (fallback5.mail.ru [94.100.181.253]) (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 B09EE7AA85 for ; Thu, 14 Dec 2017 08:34:13 +0000 (UTC) (envelope-from qroxana@mail.ru) Received: from [10.161.64.41] (port=35060 helo=smtp33.i.mail.ru) by fallback5.mail.ru with esmtp (envelope-from ) id 1ePOxx-0005qs-6m for freebsd-arm@freebsd.org; Thu, 14 Dec 2017 11:34:05 +0300 Received: by smtp33.i.mail.ru with esmtpa (envelope-from ) id 1ePOxn-0000s1-RO for freebsd-arm@freebsd.org; Thu, 14 Dec 2017 11:33:57 +0300 Date: Thu, 14 Dec 2017 08:33:46 +0000 From: qroxana To: freebsd-arm@freebsd.org Subject: Does FreeBSD support Allwinner R18? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: X-7FA49CB5: 0D63561A33F958A571F7829DC66DC1AACE829E0EEA7F1C5640A9A9DB0B5D3539725E5C173C3A84C3FD340EA919DED65B1FFC997B2FE74696BA6625F88748EAEFC4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F03FC5E6FBEB4333C3B503F486389A921A5CC5B56E945C8DA X-Mailru-Sender: FA72229A2414D4A22493479BF67F301518E7DAE7E836A90AA94E758429242E79B881E0367C2B2B309BBFFF7D229A147FFDD1F2F6C9B53D730D187FEF3E0D57C1D08349341B303650BDF7E317B72FD726EC982BF62A43B37A04568DD965327F405FEEDEB644C299C0ED14614B50AE0675 X-Mras: OK X-Mras: OK X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 08:34:15 -0000 It seems PINE 64-TLS switch from Allwinner A64 SoC to R18 https://www.pine64.org/?product=pine-a64-lts There's a sysutils/u-boot-sopine port for PINE 64-TLS, does it mean FreeBSD could be running on the PINE A64-TLS board now? Thanks, From owner-freebsd-arm@freebsd.org Thu Dec 14 10:22: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 0F0EBE9F224 for ; Thu, 14 Dec 2017 10:22:26 +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 762D17DEC3 for ; Thu, 14 Dec 2017 10:22:24 +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 58090ebd; Thu, 14 Dec 2017 11:22:17 +0100 (CET) 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=SHnuzH+BCN3xRv2EkyWBdVMAYJI=; b=G0EMFWY6nL2gM0lNheUIYEllISyq 0/i1XK4tNVPjrMg8qWpz5vtYbkB0A/5fB6lkmKRUhuCdE3SKQb++ki2ZnfdEBNMY rXq5pD3CL7v/KbOmFsjarYEybFYTMQI3U5av2LnBc5clnUNUC6pQ72YLYVKcc7fN diSQs8zAFsU18hU= 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=DalQ0uD6yL0/mI1pvNou61XMJJZol4rFl3b+2Rl9DTT31+E3Gx1MJ7fq gPJ7PEtTdxmKIjmgGwUvgp+B0m9ssr4YypxQEfdoJrqPMKW3/aXI7GiQjf/dzm4g f1H5Pt/7MAht31yYMBCcy9+rrep5ZOD5oAjjzsC4vszihI8MaFs= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 67c94661 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 14 Dec 2017 11:22:17 +0100 (CET) Date: Thu, 14 Dec 2017 11:22:16 +0100 From: Emmanuel Vadot To: qroxana Cc: qroxana via freebsd-arm Subject: Re: Does FreeBSD support Allwinner R18? Message-Id: <20171214112216.90fdfaf15a6003b24aba6e87@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.6.0 (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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 10:22:26 -0000 On Thu, 14 Dec 2017 08:33:46 +0000 qroxana via freebsd-arm wrote: > > It seems PINE 64-TLS switch from Allwinner A64 SoC to R18 > https://www.pine64.org/?product=pine-a64-lts > > There's a sysutils/u-boot-sopine port for PINE 64-TLS, > does it mean FreeBSD could be running on the PINE A64-TLS > board now? > > Thanks, Yes, R18 ~= A64, I think that it draws less power etc ... I do have the Pine64-LTS and use it, that's why the u-boot-sopine was created. The main difference between Pine64/Pine64-LTS is LPDDR3 for the LTS version (and the sopine/pinebook) hence the new u-boot. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Dec 14 19:00:36 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 751F5E8B965 for ; Thu, 14 Dec 2017 19:00:36 +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 5B57C734BD for ; Thu, 14 Dec 2017 19:00:34 +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 vBEJ0pdH066195 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Dec 2017 11:00:52 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vBEJ0pnj066194; Thu, 14 Dec 2017 11:00:51 -0800 (PST) (envelope-from fbsd) Date: Thu, 14 Dec 2017 11:00:50 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Filesystem full, but df says not. Message-ID: <20171214190050.GA66078@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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 19:00:36 -0000 An rpi2 running -current reported errors during boot like this on the serial console after a graceful reboot: UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 0, cgp: 0x4c0a5f41 != bp: 0x38b82866 UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 3, cgp: 0x58e2c1f5 != bp: 0x903c297 UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 0, cgp: 0x4c0a5f41 != bp: 0x38b82866 /: write failed, filesystem is full cp: /etc/motd: No space left on device . Mounting late filesystems:. Dec 14 10:08:56 www kernel: pid 1394 (cp), uid 0 inumber 53912 on /: filesystem full Root is on the microSD card, /usr /var /tmp and swap are on usb flash. Nevertheless, it reached multi-user and allowed me to ssh in and run df, which reported Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ufs/rootfs 1473116 479936 875332 35% / devfs 1 1 0 100% /dev /dev/msdosfs/MSDOSBOOT 51140 7588 43552 15% /boot/msdos /dev/da0e 52221244 28697844 19345704 60% /usr /dev/da0d 3044988 517860 2283532 18% /tmp /dev/da0a 2031132 122868 1745776 7% /var Still, any activity that wrote to disk repeated the filesystem full error. This happened with three different kernels, dating Dec 12, 7 and Aug 26. Running fsck -fy once in single user didn't seem to help, although it finished without obvious errors. Running fsck -fy repeatedly in single-user seems to have cleared the error, but it's a surprising development. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Thu Dec 14 19:10: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 8E143E8BF25 for ; Thu, 14 Dec 2017 19:10:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-163.reflexion.net [208.70.210.163]) (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 3D78673B0E for ; Thu, 14 Dec 2017 19:10:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11531 invoked from network); 14 Dec 2017 19:10:47 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 14 Dec 2017 19:10:47 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 14 Dec 2017 14:10:47 -0500 (EST) Received: (qmail 12189 invoked from network); 14 Dec 2017 19:10:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Dec 2017 19:10:46 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3F560EC918C; Thu, 14 Dec 2017 11:10:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Filesystem full, but df says not. From: Mark Millard In-Reply-To: <20171214190050.GA66078@www.zefox.net> Date: Thu, 14 Dec 2017 11:10:45 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171214190050.GA66078@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 19:10:54 -0000 On 2017-Dec-14, at 11:00 AM, bob prohaska wrote: > An rpi2 running -current reported errors during boot like this on the > serial console after a graceful reboot: >=20 > UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 0, cgp: = 0x4c0a5f41 !=3D bp: 0x38b82866 > UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 3, cgp: = 0x58e2c1f5 !=3D bp: 0x903c297 > UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 0, cgp: = 0x4c0a5f41 !=3D bp: 0x38b82866 Believe the above low-level messages. > /: write failed, filesystem is full > cp: /etc/motd: No space left on device My guess: Other places likely translate the more detailed error classification to more generic classifications that hopefully result in an appropriate handling of the issue but is otherwise not necessarily correct. In other words: do not believe the later related messages in all its detail. > . > Mounting late filesystems:. > Dec 14 10:08:56 www kernel: pid 1394 (cp), uid 0 inumber 53912 on /: = filesystem full >=20 > Root is on the microSD card, /usr /var /tmp and swap are on usb flash. >=20 > Nevertheless, it reached multi-user and allowed me to ssh in and run = df, > which reported > Filesystem 1K-blocks Used Avail Capacity Mounted = on > /dev/ufs/rootfs 1473116 479936 875332 35% / > devfs 1 1 0 100% /dev > /dev/msdosfs/MSDOSBOOT 51140 7588 43552 15% = /boot/msdos > /dev/da0e 52221244 28697844 19345704 60% /usr > /dev/da0d 3044988 517860 2283532 18% /tmp > /dev/da0a 2031132 122868 1745776 7% /var This activity probably did not depend on the bad cylinder checksums. > Still, any activity that wrote to disk repeated the filesystem full = error. >=20 > This happened with three different kernels, dating Dec 12, 7 and Aug = 26. > Running fsck -fy once in single user didn't seem to help, although it=20= > finished without obvious errors. Running fsck -fy repeatedly in = single-user=20 > seems to have cleared the error, but it's a surprising development. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Dec 14 19:30:22 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 DF158E8C80A for ; Thu, 14 Dec 2017 19:30:22 +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 9AD2E749EB for ; Thu, 14 Dec 2017 19:30:22 +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 vBEJUbtG066268 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Dec 2017 11:30:38 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vBEJUb04066267; Thu, 14 Dec 2017 11:30:37 -0800 (PST) (envelope-from fbsd) Date: Thu, 14 Dec 2017 11:30:37 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Filesystem full, but df says not. Message-ID: <20171214193037.GA66234@www.zefox.net> References: <20171214190050.GA66078@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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 19:30:23 -0000 On Thu, Dec 14, 2017 at 11:10:45AM -0800, Mark Millard wrote: > On 2017-Dec-14, at 11:00 AM, bob prohaska wrote: > > > > An rpi2 running -current reported errors during boot like this on the > > serial console after a graceful reboot: > > > > UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 0, cgp: 0x4c0a5f41 != bp: 0x38b82866 > > UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 3, cgp: 0x58e2c1f5 != bp: 0x903c297 > > UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 0, cgp: 0x4c0a5f41 != bp: 0x38b82866 > > Believe the above low-level messages. > > > /: write failed, filesystem is full > > cp: /etc/motd: No space left on device > > My guess: > > Other places likely translate the more detailed error > classification to more generic classifications that > hopefully result in an appropriate handling of the issue > but is otherwise not necessarily correct. > > In other words: do not believe the later related messages > in all its detail. > > > . > > Mounting late filesystems:. > > Dec 14 10:08:56 www kernel: pid 1394 (cp), uid 0 inumber 53912 on /: filesystem full > > > > Root is on the microSD card, /usr /var /tmp and swap are on usb flash. > > > > Nevertheless, it reached multi-user and allowed me to ssh in and run df, > > which reported > > Filesystem 1K-blocks Used Avail Capacity Mounted on > > /dev/ufs/rootfs 1473116 479936 875332 35% / > > devfs 1 1 0 100% /dev > > /dev/msdosfs/MSDOSBOOT 51140 7588 43552 15% /boot/msdos > > /dev/da0e 52221244 28697844 19345704 60% /usr > > /dev/da0d 3044988 517860 2283532 18% /tmp > > /dev/da0a 2031132 122868 1745776 7% /var > > This activity probably did not depend on the bad cylinder > checksums. > > > Still, any activity that wrote to disk repeated the filesystem full error. > > > > This happened with three different kernels, dating Dec 12, 7 and Aug 26. > > Running fsck -fy once in single user didn't seem to help, although it > > finished without obvious errors. Running fsck -fy repeatedly in single-user > > seems to have cleared the error, but it's a surprising development. > > Is there any user utility more rigorous than fsck to inspect the filesystem? The machine is now building world without obvious distress. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Thu Dec 14 20:56:57 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78BC5E8F8B9 for ; Thu, 14 Dec 2017 20:56:57 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 53B8A79771 for ; Thu, 14 Dec 2017 20:56:56 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBEKupx0098817; Thu, 14 Dec 2017 12:56:51 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBEKupPm098816; Thu, 14 Dec 2017 12:56:51 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712142056.vBEKupPm098816@pdx.rh.CN85.dnsmgr.net> Subject: Re: Filesystem full, but df says not. In-Reply-To: To: Mark Millard Date: Thu, 14 Dec 2017 12:56:51 -0800 (PST) CC: bob prohaska , freebsd-arm@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 20:56:57 -0000 > On 2017-Dec-14, at 11:00 AM, bob prohaska wrote: > > > > An rpi2 running -current reported errors during boot like this on the > > serial console after a graceful reboot: > > > > UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 0, cgp: 0x4c0a5f41 != bp: 0x38b82866 > > UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 3, cgp: 0x58e2c1f5 != bp: 0x903c297 > > UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 0, cgp: 0x4c0a5f41 != bp: 0x38b82866 > > Believe the above low-level messages. And be aware that when a cg checksum fails that CG's freespace is no longer avaliable to be used until the CG checksum has been corrected by a fsck. You are probably moving your file system accross the "has CG checksum" and "does not have CG checksum" boundary and when you do that your older kernel does not write the checksum and your newer kernel gets upset about that. > > /: write failed, filesystem is full > > cp: /etc/motd: No space left on device This error is correct, as the free space in your CG is not avaliable as that CG has failed chksum. > > My guess: > > Other places likely translate the more detailed error > classification to more generic classifications that > hopefully result in an appropriate handling of the issue > but is otherwise not necessarily correct. It is correct as stated, for the reasons I state. > > In other words: do not believe the later related messages > in all its detail. Oh believe it! > > . > > Mounting late filesystems:. > > Dec 14 10:08:56 www kernel: pid 1394 (cp), uid 0 inumber 53912 on /: filesystem full > > > > Root is on the microSD card, /usr /var /tmp and swap are on usb flash. > > > > Nevertheless, it reached multi-user and allowed me to ssh in and run df, > > which reported > > Filesystem 1K-blocks Used Avail Capacity Mounted on > > /dev/ufs/rootfs 1473116 479936 875332 35% / > > devfs 1 1 0 100% /dev > > /dev/msdosfs/MSDOSBOOT 51140 7588 43552 15% /boot/msdos > > /dev/da0e 52221244 28697844 19345704 60% /usr > > /dev/da0d 3044988 517860 2283532 18% /tmp > > /dev/da0a 2031132 122868 1745776 7% /var > > This activity probably did not depend on the bad cylinder > checksums. > > > Still, any activity that wrote to disk repeated the filesystem full error. > > > > This happened with three different kernels, dating Dec 12, 7 and Aug 26. > > Running fsck -fy once in single user didn't seem to help, although it > > finished without obvious errors. Running fsck -fy repeatedly in single-user > > seems to have cleared the error, but it's a surprising development. > > > === > 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" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Thu Dec 14 20:59:38 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4105CE8F9BA for ; Thu, 14 Dec 2017 20:59:38 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 1843B7990D for ; Thu, 14 Dec 2017 20:59:37 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBEKxYuk098833; Thu, 14 Dec 2017 12:59:34 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBEKxYn7098832; Thu, 14 Dec 2017 12:59:34 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712142059.vBEKxYn7098832@pdx.rh.CN85.dnsmgr.net> Subject: Re: Filesystem full, but df says not. In-Reply-To: <20171214193037.GA66234@www.zefox.net> To: bob prohaska Date: Thu, 14 Dec 2017 12:59:34 -0800 (PST) CC: Mark Millard , freebsd-arm@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 20:59:38 -0000 > On Thu, Dec 14, 2017 at 11:10:45AM -0800, Mark Millard wrote: > > On 2017-Dec-14, at 11:00 AM, bob prohaska wrote: > > > > > > > An rpi2 running -current reported errors during boot like this on the > > > serial console after a graceful reboot: > > > > > > UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 0, cgp: 0x4c0a5f41 != bp: 0x38b82866 > > > UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 3, cgp: 0x58e2c1f5 != bp: 0x903c297 > > > UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 0, cgp: 0x4c0a5f41 != bp: 0x38b82866 > > > > Believe the above low-level messages. > > > > > /: write failed, filesystem is full > > > cp: /etc/motd: No space left on device > > > > My guess: > > > > Other places likely translate the more detailed error > > classification to more generic classifications that > > hopefully result in an appropriate handling of the issue > > but is otherwise not necessarily correct. > > > > In other words: do not believe the later related messages > > in all its detail. > > > > > . > > > Mounting late filesystems:. > > > Dec 14 10:08:56 www kernel: pid 1394 (cp), uid 0 inumber 53912 on /: filesystem full > > > > > > Root is on the microSD card, /usr /var /tmp and swap are on usb flash. > > > > > > Nevertheless, it reached multi-user and allowed me to ssh in and run df, > > > which reported > > > Filesystem 1K-blocks Used Avail Capacity Mounted on > > > /dev/ufs/rootfs 1473116 479936 875332 35% / > > > devfs 1 1 0 100% /dev > > > /dev/msdosfs/MSDOSBOOT 51140 7588 43552 15% /boot/msdos > > > /dev/da0e 52221244 28697844 19345704 60% /usr > > > /dev/da0d 3044988 517860 2283532 18% /tmp > > > /dev/da0a 2031132 122868 1745776 7% /var > > > > This activity probably did not depend on the bad cylinder > > checksums. > > > > > Still, any activity that wrote to disk repeated the filesystem full error. > > > > > > This happened with three different kernels, dating Dec 12, 7 and Aug 26. > > > Running fsck -fy once in single user didn't seem to help, although it > > > finished without obvious errors. Running fsck -fy repeatedly in single-user > > > seems to have cleared the error, but it's a surprising development. > > > > > > Is there any user utility more rigorous than fsck to inspect the filesystem? > > The machine is now building world without obvious distress. > > Thanks for reading! I should of pointed out that to clear up the bad CG checksum you should run a fsck -f on the device and answer Y, this is NOT the same as running fsck -fy, see a modern man fsck. I also believe Kirk is working on some thing that should remove this annoying problem. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Thu Dec 14 21:58:47 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 745DFE912C2 for ; Thu, 14 Dec 2017 21:58:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-151.reflexion.net [208.70.210.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 368047B641 for ; Thu, 14 Dec 2017 21:58:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23661 invoked from network); 14 Dec 2017 21:58:40 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 14 Dec 2017 21:58:40 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 14 Dec 2017 16:58:40 -0500 (EST) Received: (qmail 26951 invoked from network); 14 Dec 2017 21:58:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Dec 2017 21:58:40 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7F61FEC956A; Thu, 14 Dec 2017 13:58:39 -0800 (PST) From: Mark Millard Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Filesystem full, but df says not. Date: Thu, 14 Dec 2017 13:58:38 -0800 In-Reply-To: <201712142056.vBEKupPm098816@pdx.rh.CN85.dnsmgr.net> Cc: bob prohaska , freebsd-arm@freebsd.org To: "Rodney W. Grimes" References: <201712142056.vBEKupPm098816@pdx.rh.CN85.dnsmgr.net> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 21:58:47 -0000 On 2017-Dec-14, at 12:56 PM, Rodney W. Grimes wrote: >>> On 2017-Dec-14, at 11:00 AM, bob prohaska = wrote: >>>=20 >>>=20 >>>> An rpi2 running -current reported errors during boot like this on = the >>>> serial console after a graceful reboot: >>>>=20 >>>> UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 0, cgp: = 0x4c0a5f41 !=3D bp: 0x38b82866 >>>> UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 3, cgp: = 0x58e2c1f5 !=3D bp: 0x903c297 >>>> UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 0, cgp: = 0x4c0a5f41 !=3D bp: 0x38b82866 >>>=20 >>> Believe the above low-level messages. >>=20 >> And be aware that when a cg checksum fails that CG's freespace is no >> longer avaliable to be used until the CG checksum has been corrected >> by a fsck. >>=20 >> You are probably moving your file system accross the "has CG = checksum" >> and "does not have CG checksum" boundary and when you do that your >> older kernel does not write the checksum and your newer kernel gets >> upset about that. >>=20 >>=20 >>>> /: write failed, filesystem is full >>>> cp: /etc/motd: No space left on device >>=20 >> This error is correct, as the free space in your CG is not avaliable = as >> that CG has failed chksum.=20 I see. Just not how I took the phrase "filesystem is full". Now the file system can be full when df shows space available. That will tend to seem odd to folks. >>>=20 >>> My guess: >>>=20 >>> Other places likely translate the more detailed error >>> classification to more generic classifications that >>> hopefully result in an appropriate handling of the issue >>> but is otherwise not necessarily correct. >>=20 >> It is correct as stated, for the reasons I state. >>=20 >>>=20 >>> In other words: do not believe the later related messages >>> in all its detail. >>=20 >> Oh believe it! Sorry for the misinterpretation. >> . >> Mounting late filesystems:. >> Dec 14 10:08:56 www kernel: pid 1394 (cp), uid 0 inumber 53912 on /: = filesystem full >>=20 >> Root is on the microSD card, /usr /var /tmp and swap are on usb = flash. >>=20 >> Nevertheless, it reached multi-user and allowed me to ssh in and = run df, >> which reported >> Filesystem 1K-blocks Used Avail Capacity Mounted = on >> /dev/ufs/rootfs 1473116 479936 875332 35% / >> devfs 1 1 0 100% /dev >> /dev/msdosfs/MSDOSBOOT 51140 7588 43552 15% = /boot/msdos >> /dev/da0e 52221244 28697844 19345704 60% /usr >> /dev/da0d 3044988 517860 2283532 18% /tmp >> /dev/da0a 2031132 122868 1745776 7% /var The above sort of result becomes the odd thing for people to understand the classification. > This activity probably did not depend on the bad cylinder > checksums. >=20 >> Still, any activity that wrote to disk repeated the filesystem full = error. >>=20 >> This happened with three different kernels, dating Dec 12, 7 and Aug = 26. >> Running fsck -fy once in single user didn't seem to help, although it=20= >> finished without obvious errors. Running fsck -fy repeatedly in = single-user=20 >> seems to have cleared the error, but it's a surprising development. >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Dec 15 08:41: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 A7211E9F79C for ; Fri, 15 Dec 2017 08:41:59 +0000 (UTC) (envelope-from unto.foru13@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E24B6D241 for ; Fri, 15 Dec 2017 08:41:59 +0000 (UTC) (envelope-from unto.foru13@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id r78so15956129wme.5 for ; Fri, 15 Dec 2017 00:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=o/D+kCDNsb4jlkZnqZS2SQi0UjzKsC/3YVrTo1sbpuM=; b=PZdypksfChqFO8ubKsx3DMBP6PbTa05gy2xA6lZ/5Wwv9WkgVNpHLrXXwWx6zxrkne cqNn+W1HvMnfmsutOT0dYIYcg9icTX7exHYsWDTVpNy1x51mseV5MRjQCqzye0Ekm6JO F+9OBG8C7Bs3U7kH+F4XQcByGhlcg9tMCHjFbBVIVBA7+crTiG07mNf9IUeUlaETnRXR hjr5gNgfgIE1ZQg8tV0e1bQ5Lx5StBABllQigdCY/nq0xXyozhiQ4F84CYM2u4j5mgz7 g4azPni3rFbxwW3jSx55wI0Le9vsqK968C2ZgRaWc2Vv/qDPHO8KfcrfJEjpFoEAe48X yVFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=o/D+kCDNsb4jlkZnqZS2SQi0UjzKsC/3YVrTo1sbpuM=; b=m2owfUmuAjFZ+0lgwpd6/kT2jYbqOKg+etgBuckFS/rGFHUilXL9SxfGHN8/opjCWU jkQT0i065pn5S+qqsQl/ZZ/szRUOCRIiHV+1qLacvh7bKZdEMD/NPAgvRS3MApUC27La 4BdedT5zaYG4MZm+eFxPLnfYYxY4GwfpS4vubehq8C1J1+cKIyHF7h8ICCXzIu3NLDUX ju9+iQkyIxdLD1k0y6SxPSiuCoS8A1OUuJdfzZ9Bv5TGvbfqmIoFeZD3NsrEt7qMISpD BkzIx6jAP5dExt3OGId+jlHcU1o4j1TTjcgaS1DMo+gtD1QK73ISfa/BrspxxjRC/WeP gSqw== X-Gm-Message-State: AKGB3mKwCVjLoWa2emQEf25MijvrtMF9PAsmgq+HUA4uTorOTfX3B3vM QGGJ4goVpkyJ2GWkR2rXiNtewYWWOlU6jBtlfcSP5g== X-Google-Smtp-Source: ACJfBotLPuecBaUCopgEHwpXPHdQ/MwZV37pvt4Sratl8NfqC77qu8tTuW8Pt6my4jtkhHXThIeg1IgWPHDf9Wxfjyc= X-Received: by 10.80.207.143 with SMTP id h15mr16056517edk.189.1513327316989; Fri, 15 Dec 2017 00:41:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.219.73 with HTTP; Fri, 15 Dec 2017 00:41:56 -0800 (PST) From: =?UTF-8?B?6Zi/6YeR?= Date: Fri, 15 Dec 2017 16:41:56 +0800 Message-ID: Subject: Orange pi one plug network cable after booted , network will not active To: freebsd-arm@freebsd.org, Emmanuel Vadot , Mark Millard Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 08:41:59 -0000 Dear all, I think ,this maybe is the problem of u-boot.dtb?? scenario1:plug network cable first then power on,kernel had loaded. network will work well. even if I plug off cable then plug on again .network work well too. scenario2:network cable not plug till kernel had loaded and prompt login message. booting message=>awg0:soft reset timed out then I plug network cable ,network will not work. ifconfig will not show awg0. /etc/netstart will show => ifconfig: interface awg0 does not exist blow is my u-boot source https://github.com/evadot/u-boot/tree/freebsd export CROSS_COMPILE=arm-none-eabi- gmake orangepi_one_defconfig gmake menuconfig vi .config CONFIG_API=y gmake how could I fixed this problem ?? thanks all. From owner-freebsd-arm@freebsd.org Fri Dec 15 09:21: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 13666EA09E3 for ; Fri, 15 Dec 2017 09:21:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-97.reflexion.net [208.70.210.97]) (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 C79086E5BC for ; Fri, 15 Dec 2017 09:21:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16041 invoked from network); 15 Dec 2017 09:21:09 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 15 Dec 2017 09:21:09 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 15 Dec 2017 04:21:09 -0500 (EST) Received: (qmail 12713 invoked from network); 15 Dec 2017 09:21:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Dec 2017 09:21:09 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 68101EC9380 for ; Fri, 15 Dec 2017 01:21:08 -0800 (PST) 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: Fairly minimal sdcard content for booting kernel and world on an RPI2 V1.1 from a USB SSD instead of from the sdcard Message-Id: <96279C4C-C713-48E1-AD5F-178852C04B45@dsl-only.net> Date: Fri, 15 Dec 2017 01:21:07 -0800 To: Freebsd-arm X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 09:21:17 -0000 For the following the sdcard can be removed after the kernel starts to load from the USB drive (in my context a USB SSD stick). =46rom gpart show (sdcard plugged in someplace else via USB): =3D> 63 62521281 da4 MBR (30G) 63 102375 da4s1 !12 [active] (50M) 102438 56623098 da4s2 freebsd (27G) 56725536 5795808 - free - (2.8G) =3D> 0 56623098 da4s2 BSD (27G) 0 90 - free - (45K) 90 56623008 da4s2a freebsd-ufs (27G) (I did not bother to shrink the ufs partition on s2a or s2 itself. But little space is needed.) For /media being where I mounted s1 in order to show it: # du -Asm /media/* 1 /media/BOOTCODE.BIN 1 /media/CONFIG.TXT 1 /media/FIXUP.DAT 1 /media/FIXUP_CD.DAT 1 /media/FIXUP_X.DAT 1 /media/LICENCE.broadcom 1 /media/README 3 /media/START.ELF 1 /media/START_CD.ELF 4 /media/START_X.ELF 1 /media/U-BOOT.BIN 1 /media/fixup_db.dat 5 /media/start_db.elf 1 /media/ubldr.bin So. . . Ports based: sysutils/rpi-firmware content sysutils/u-boot-rpi2 content installworld copy based: boot/ubldr.bin copy # du -Asm /usr/local/share/rpi-firmware = /usr/local/share/u-boot/u-boot-rpi2 12 /usr/local/share/rpi-firmware 1 /usr/local/share/u-boot/u-boot-rpi2 (I do not repeat the port instructions here.) For /mnt being where I mounted s2a in order to show it: # du -Asm /mnt/*/* 1 /mnt/boot/beastie.4th 1 /mnt/boot/boot1.efi 1 /mnt/boot/boot1.efifat 1 /mnt/boot/brand-fbsd.4th 1 /mnt/boot/brand.4th 1 /mnt/boot/check-password.4th 1 /mnt/boot/color.4th 1 /mnt/boot/defaults 1 /mnt/boot/delay.4th 3 /mnt/boot/dtb 1 /mnt/boot/efi.4th 1 /mnt/boot/entropy 1 /mnt/boot/firmware 1 /mnt/boot/frames.4th 1 /mnt/boot/loader.4th 1 /mnt/boot/loader.conf 1 /mnt/boot/loader.efi 1 /mnt/boot/loader.help 1 /mnt/boot/loader.rc 1 /mnt/boot/logo-beastie.4th 1 /mnt/boot/logo-beastiebw.4th 1 /mnt/boot/logo-fbsdbw.4th 1 /mnt/boot/logo-orb.4th 1 /mnt/boot/logo-orbbw.4th 1 /mnt/boot/menu-commands.4th 1 /mnt/boot/menu.4th 1 /mnt/boot/menu.rc 1 /mnt/boot/menu.rc.sample 1 /mnt/boot/menusets.4th 1 /mnt/boot/modules 1 /mnt/boot/msdos 1 /mnt/boot/pcibios.4th 1 /mnt/boot/screen.4th 1 /mnt/boot/shortcuts.4th 1 /mnt/boot/support.4th 1 /mnt/boot/ubldr 1 /mnt/boot/ubldr.bin 1 /mnt/boot/version.4th 1 /mnt/boot/zfs 1 /mnt/etc/fstab (I'll not list all the dtb files in the dtb directory.) # df -m /mnt Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/da4s2a 26763 5 24617 0% /mnt (So not much space needed.) # more /mnt/etc/fstab /dev/da0p1 / ufs rw,noatime 1 1 /dev/da0p2 none swap sw 0 0 fstab used notation for the root file system that ubldr.bin could interpret on its own. Of course, for the /dev/da0p1 and /dev/da0p2 notation for the USB SSD, it can be important that other USB drives not be plugged in yet or the paths needed might be different. As for populating boot/ above: Having done an installkernel and installworld locally in order to copy selectively to the sdcard's s2a UFS partition: # du -Asm /usr/obj/DESTDIRs/clang-armv7-installworld/boot/* = /usr/obj/DESTDIRs/clang-armv7-installkernel/boot/dtb | more 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/beastie.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/boot1.efi 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/boot1.efifat 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/brand-fbsd.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/brand.4th 1 = /usr/obj/DESTDIRs/clang-armv7-installworld/boot/check-password.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/color.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/defaults 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/delay.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/dtb 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/efi.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/firmware 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/frames.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/kernel 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/loader.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/loader.efi 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/loader.help 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/loader.rc 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/logo-beastie.4th 1 = /usr/obj/DESTDIRs/clang-armv7-installworld/boot/logo-beastiebw.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/logo-fbsdbw.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/logo-orb.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/logo-orbbw.4th 1 = /usr/obj/DESTDIRs/clang-armv7-installworld/boot/menu-commands.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/menu.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/menu.rc 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/menusets.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/modules 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/pcibios.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/screen.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/shortcuts.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/support.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/ubldr 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/ubldr.bin 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/version.4th 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/zfs 3 /usr/obj/DESTDIRs/clang-armv7-installkernel/boot/dtb Copy (my paths are just examples): cp -ax /usr/obj/DESTDIRs/clang-armv7-installworld/boot /mnt/ cp -ax /usr/obj/DESTDIRs/clang-armv7-installkernel/boot/dtb /mnt/boot/ (Updates may mean cleaning out older directory/file names.) (A more selective copy should be possible but gets into tracking potential changes in what files are required more carefully.) [For UFS the mounts presume endian matching, here little endian.] [In my context, the USB SSD stick is on a powered hub that is plugged into the RPI2-B V1.1 .] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Dec 15 16:02: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 0D8ADE85255 for ; Fri, 15 Dec 2017 16:02:29 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD3B77B47A for ; Fri, 15 Dec 2017 16:02:28 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1ePsHD-0009Cb-UV; Fri, 15 Dec 2017 17:51:55 +0200 From: Daniel Braniss Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: orangepi-zero serial (not the debug port) now working Message-Id: Date: Fri, 15 Dec 2017 17:51:55 +0200 Cc: freebsd-arm@freebsd.org To: Milan Obuch X-Mailer: Apple Mail (2.3445.4.7) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:02:29 -0000 hi, after a week of failing to get the usb to work, this little change to = the dts file did the trick: --- /r+d/vanilla/12/sys/gnu/dts/arm/sun8i-h2-plus-orangepi-zero.dts = 2017-12-02 16:29:32.134790000 +0200 +++ ./sun8i-h2-plus-orangepi-zero.dts 2017-12-15 17:34:25.742903000 = +0200 @@ -164,7 +164,7 @@ &uart1 { pinctrl-names =3D "default"; pinctrl-0 =3D <&uart1_pins>; - status =3D "disabled"; + status =3D "okay"; }; &uart2 { and now I have a working /dev/ttyu1! BTW, this is with a resent CURRENT. danny From owner-freebsd-arm@freebsd.org Fri Dec 15 16:05: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 DA66BE85308 for ; Fri, 15 Dec 2017 16:05:06 +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 55EE87B53D for ; Fri, 15 Dec 2017 16:05:06 +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 f8e7b5de; Fri, 15 Dec 2017 17:04:57 +0100 (CET) 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=Ypz2SFuAu1iKABtyX40FcULmWsE=; b=FqNj4nwkzJQome4cb9Gn4LsB/q9b 88RIcY0txCJsJI0uqOJIxR9SwIaTvcMfCHf/KrfBkel6CC+CdQ+psc+oUX+0ILY1 N1veDTTeWwBP1JzKIMjb4CisCoBN0So9U64xIdlyE/RdCiTANXK4WMBXTNXxo2Ag yH9RNKkA5XutGTU= 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=YVzTRtd7Kv5/+hiENlIpXHBRW/1qIHGPT90StowyKrQTIEdesJb7p1xQ SyhpM6HRL0Ouasr8ZSmlulP/t00JA9KHsCGJInqoFhb1bngmu6c4Rx+YZunJ0Mfs dhKgIlZ0nS6U3JFYEkT1Uq+I475/dBAuoXpZjscaHOXAwrAQvhk= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id dde11ba7 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 15 Dec 2017 17:04:57 +0100 (CET) Date: Fri, 15 Dec 2017 17:04:57 +0100 From: Emmanuel Vadot To: Daniel Braniss Cc: Milan Obuch , freebsd-arm@freebsd.org Subject: Re: orangepi-zero serial (not the debug port) now working Message-Id: <20171215170457.e2fd35d8299c3825efffe3b8@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.6.0 (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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:05:06 -0000 On Fri, 15 Dec 2017 17:51:55 +0200 Daniel Braniss wrote: > hi, > after a week of failing to get the usb to work, this little change to the dts file did the trick: USB ? > --- /r+d/vanilla/12/sys/gnu/dts/arm/sun8i-h2-plus-orangepi-zero.dts 2017-12-02 16:29:32.134790000 +0200 > +++ ./sun8i-h2-plus-orangepi-zero.dts 2017-12-15 17:34:25.742903000 +0200 > @@ -164,7 +164,7 @@ > &uart1 { > pinctrl-names = "default"; > pinctrl-0 = <&uart1_pins>; > - status = "disabled"; > + status = "okay"; > }; > > &uart2 { > > and now I have a working /dev/ttyu1! > BTW, this is with a resent CURRENT. > > danny This is expected, node aren't enabled if there is nothing using it on the board. For something like that you might want to look at overlays instead of modifying main dtb. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Fri Dec 15 16:06:22 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 F1406E85383 for ; Fri, 15 Dec 2017 16:06:22 +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 66B397B5BE for ; Fri, 15 Dec 2017 16:06:21 +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 c367a0f8; Fri, 15 Dec 2017 17:06:19 +0100 (CET) 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=cpp+RZK0N0vZOIZomf660W3nVBM=; b=PO1sEyjHz05k52mUPLX1R9WFXKl6 nOEhS3qEv/llfiIMuz3IO1fhhdxeT3nR3GlWLlifEP1EOQseMHv3CwmcE/6mAo73 4GtY4IpxriVYA8AnpqsmwdLpzZJRz73/L/YoNzRBItyt8rvwNDFV8kgQkoxLL9+n yUMJe872FqFxJxM= 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=Od0LUwTkIrcvWLJiscopFE0xEqOcft4gqg7VVQ5Obej2tDqpKwqKwCn5 gqcgdAt0AKVwMuoSsd9K9YvWqCIeYfvMDunATxFxcncTtdW1RPDdL9MBExpNmFhl YKK+WtFgj54WTFwuwhof7Rn44B0ofIQRJjjS7R6BmHi2UshzQFA= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id bf6e80eb TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 15 Dec 2017 17:06:19 +0100 (CET) Date: Fri, 15 Dec 2017 17:06:19 +0100 From: Emmanuel Vadot To: =?ISO-8859-1?Q?=3F=3F?= Cc: freebsd-arm@freebsd.org, Mark Millard Subject: Re: Orange pi one plug network cable after booted ,network will not active Message-Id: <20171215170619.8021fb253a15f3e54a356f9a@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:06:23 -0000 On Fri, 15 Dec 2017 16:41:56 +0800 ?? wrote: > Dear all, >=20 > I think ,this maybe is the problem of u-boot.dtb?? >=20 > scenario1:plug network cable first then power on,kernel had loaded. > network will work well. > even if I plug off cable then plug on again .network work well too. >=20 > scenario2:network cable not plug till kernel had loaded and prompt login > message. >=20 > booting message=3D>awg0:soft reset timed out >=20 > then I plug network cable ,network will not work. > ifconfig will not show awg0. > /etc/netstart will show =3D> ifconfig: interface awg0 does not exist >=20 > blow is my u-boot source > https://github.com/evadot/u-boot/tree/freebsd >=20 > export CROSS_COMPILE=3Darm-none-eabi- > gmake orangepi_one_defconfig > gmake menuconfig > vi .config > CONFIG_API=3Dy > gmake >=20 > how could I fixed this problem ?? > thanks all. I'll look into it but note that emac (if_awg) isn't in the dts for now and only will be when we pull the Liunx 4.15 dts (early january). --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Fri Dec 15 16:13:55 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3CF8E856B6 for ; Fri, 15 Dec 2017 16:13:55 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 35AC67BA40 for ; Fri, 15 Dec 2017 16:13:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1ePscP-000BwX-8t; Fri, 15 Dec 2017 18:13:49 +0200 From: Daniel Braniss Message-Id: <3320CA1F-4019-4D16-AB0B-2D7DFEC71B96@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: orangepi-zero serial (not the debug port) now working Date: Fri, 15 Dec 2017 18:13:49 +0200 In-Reply-To: <20171215170457.e2fd35d8299c3825efffe3b8@bidouilliste.com> Cc: Milan Obuch , freebsd-arm@freebsd.org To: Emmanuel Vadot References: <20171215170457.e2fd35d8299c3825efffe3b8@bidouilliste.com> X-Mailer: Apple Mail (2.3445.4.7) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:13:55 -0000 > On 15 Dec 2017, at 18:04, Emmanuel Vadot = wrote: >=20 > On Fri, 15 Dec 2017 17:51:55 +0200 > Daniel Braniss > = wrote: >=20 >> hi, >> after a week of failing to get the usb to work, this little change to = the dts file did the trick: >=20 > USB ? long version: my first attempt at using the serial port failed, I then tried = using a serial to usb (which works fine on RPI and amd64) on all my allwinners and failed.=20 >=20 >> --- /r+d/vanilla/12/sys/gnu/dts/arm/sun8i-h2-plus-orangepi-zero.dts = 2017-12-02 16:29:32.134790000 +0200 >> +++ ./sun8i-h2-plus-orangepi-zero.dts 2017-12-15 17:34:25.742903000 = +0200 >> @@ -164,7 +164,7 @@ >> &uart1 { >> pinctrl-names =3D "default"; >> pinctrl-0 =3D <&uart1_pins>; >> - status =3D "disabled"; >> + status =3D "okay"; >> }; >>=20 >> &uart2 { >>=20 >> and now I have a working /dev/ttyu1! >> BTW, this is with a resent CURRENT. >>=20 >> danny >=20 > This is expected, node aren't enabled if there is nothing using it on > the board. > For something like that you might want to look at overlays instead of > modifying main dtb. this was a proof of concept, i will try doing the overlay thingy later. thanks danny >=20 > --=20 > Emmanuel Vadot > = > From owner-freebsd-arm@freebsd.org Fri Dec 15 16:16: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 DF7E3E8574B for ; Fri, 15 Dec 2017 16:16:42 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 70DAC7BB01 for ; Fri, 15 Dec 2017 16:16:42 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1ePsf9-000C4m-ON; Fri, 15 Dec 2017 18:16:39 +0200 From: Daniel Braniss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: Orange pi one plug network cable after booted ,network will not active Date: Fri, 15 Dec 2017 18:16:39 +0200 In-Reply-To: <20171215170619.8021fb253a15f3e54a356f9a@bidouilliste.com> Cc: ?? , freebsd-arm@freebsd.org To: Emmanuel Vadot References: <20171215170619.8021fb253a15f3e54a356f9a@bidouilliste.com> X-Mailer: Apple Mail (2.3445.4.7) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:16:43 -0000 > On 15 Dec 2017, at 18:06, Emmanuel Vadot = wrote: >=20 > On Fri, 15 Dec 2017 16:41:56 +0800 > ?? > wrote: >=20 >> Dear all, >>=20 >> I think ,this maybe is the problem of u-boot.dtb?? >>=20 >> scenario1:plug network cable first then power on,kernel had loaded. >> network will work well. >> even if I plug off cable then plug on again .network work well too. >>=20 >> scenario2:network cable not plug till kernel had loaded and prompt = login >> message. >>=20 >> booting message=3D>awg0:soft reset timed out >>=20 >> then I plug network cable ,network will not work. >> ifconfig will not show awg0. >> /etc/netstart will show =3D> ifconfig: interface awg0 does not exist >>=20 >> blow is my u-boot source >> https://github.com/evadot/u-boot/tree/freebsd >>=20 >> export CROSS_COMPILE=3Darm-none-eabi- >> gmake orangepi_one_defconfig >> gmake menuconfig >> vi .config >> CONFIG_API=3Dy >> gmake >>=20 >> how could I fixed this problem ?? >> thanks all. >=20 > I'll look into it but note that emac (if_awg) isn't in the dts for now > and only will be when we pull the Liunx 4.15 dts (early january). that=E2=80=99s great news!!! >=20 > --=20 > Emmanuel Vadot > = > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm = > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = " From owner-freebsd-arm@freebsd.org Fri Dec 15 16:53:47 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 1D385E863C6 for ; Fri, 15 Dec 2017 16:53:47 +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 8BEA27CD10 for ; Fri, 15 Dec 2017 16:53:45 +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 0205ca66; Fri, 15 Dec 2017 17:53:43 +0100 (CET) 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=jYPloFV2W9Z1KsmwVMpW29HWro4=; b=J/DhQH1J2cJERNUOpHCL00ABx0qG davVCVB8JdGwfWPFoT2S0TpeN+w6Dk8oabXxVMz/b5fgLWWGZeo2FPf4aGcl1wYD Rbrj4MzmysKDm/180411Afq+iYtT7FDBo1XGFPJRxjGklE4AJdahjYy7Ny+s/azs hMxOv+Xt0dShf/Q= 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=HubCB4Ra1u2P9wydhzDmIB68ujMGzPNmdrb0A1ej+oNyt7tbm5D4HSiv j4XISKjsYHdJPAFaCf72BbntXnxKhuYj5TLeIJj91BYi94Q9QQTHbsUGMcAaozCQ PCBEvRoRU+vBJ4A1v0CCMDkm46wUtQO6SfKrX7Ome91TsuVl1D4= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id cdbbc884 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 15 Dec 2017 17:53:43 +0100 (CET) Date: Fri, 15 Dec 2017 17:53:43 +0100 From: Emmanuel Vadot To: Daniel Braniss Cc: Milan Obuch , freebsd-arm@freebsd.org Subject: Re: orangepi-zero serial (not the debug port) now working Message-Id: <20171215175343.c2e3cc3efc99f0a49f879942@bidouilliste.com> In-Reply-To: <3320CA1F-4019-4D16-AB0B-2D7DFEC71B96@cs.huji.ac.il> References: <20171215170457.e2fd35d8299c3825efffe3b8@bidouilliste.com> <3320CA1F-4019-4D16-AB0B-2D7DFEC71B96@cs.huji.ac.il> X-Mailer: Sylpheed 3.6.0 (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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:53:47 -0000 On Fri, 15 Dec 2017 18:13:49 +0200 Daniel Braniss wrote: > > > > On 15 Dec 2017, at 18:04, Emmanuel Vadot wrote: > > > > On Fri, 15 Dec 2017 17:51:55 +0200 > > Daniel Braniss > wrote: > > > >> hi, > >> after a week of failing to get the usb to work, this little change to the dts file did the trick: > > > > USB ? > long version: > my first attempt at using the serial port failed, I then tried using a serial to usb (which works fine on RPI and amd64) ^^^^^^^^^^^^^ This is the part I don't understand. > on all my allwinners and failed. > > > >> --- /r+d/vanilla/12/sys/gnu/dts/arm/sun8i-h2-plus-orangepi-zero.dts 2017-12-02 16:29:32.134790000 +0200 > >> +++ ./sun8i-h2-plus-orangepi-zero.dts 2017-12-15 17:34:25.742903000 +0200 > >> @@ -164,7 +164,7 @@ > >> &uart1 { > >> pinctrl-names = "default"; > >> pinctrl-0 = <&uart1_pins>; > >> - status = "disabled"; > >> + status = "okay"; > >> }; > >> > >> &uart2 { > >> > >> and now I have a working /dev/ttyu1! > >> BTW, this is with a resent CURRENT. > >> > >> danny > > > > This is expected, node aren't enabled if there is nothing using it on > > the board. > > For something like that you might want to look at overlays instead of > > modifying main dtb. > > this was a proof of concept, i will try doing the overlay thingy later. > thanks > danny > > > > > > -- > > Emmanuel Vadot > > > -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sat Dec 16 03:18:44 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C1A1E99456 for ; Sat, 16 Dec 2017 03:18:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-152.reflexion.net [208.70.210.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A6D173E92 for ; Sat, 16 Dec 2017 03:18:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12448 invoked from network); 16 Dec 2017 03:11:57 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 16 Dec 2017 03:11:57 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 15 Dec 2017 22:11:57 -0500 (EST) Received: (qmail 5780 invoked from network); 16 Dec 2017 03:11:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Dec 2017 03:11:57 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E28FCEC7848 for ; Fri, 15 Dec 2017 19:11:56 -0800 (PST) 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: Fairly minimal sdcard content for booting kernel and world on an RPI2 V1.1 from a USB SSD instead of from the sdcard Date: Fri, 15 Dec 2017 19:11:56 -0800 References: <96279C4C-C713-48E1-AD5F-178852C04B45@dsl-only.net> To: Freebsd-arm In-Reply-To: <96279C4C-C713-48E1-AD5F-178852C04B45@dsl-only.net> Message-Id: <72C5DCE8-2B63-4F23-94B4-5C74E47CF89C@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 03:18:44 -0000 [The sdcard does not need the *.dtb files in the UFS file system's boot/dtb/ .] On 2017-Dec-15, at 1:21 AM, Mark Millard wrote: > For the following the sdcard can be removed > after the kernel starts to load from the > USB drive (in my context a USB SSD stick). >=20 > =46rom gpart show (sdcard plugged in someplace > else via USB): >=20 > =3D> 63 62521281 da4 MBR (30G) > 63 102375 da4s1 !12 [active] (50M) > 102438 56623098 da4s2 freebsd (27G) > 56725536 5795808 - free - (2.8G) >=20 > =3D> 0 56623098 da4s2 BSD (27G) > 0 90 - free - (45K) > 90 56623008 da4s2a freebsd-ufs (27G) >=20 > (I did not bother to shrink the ufs partition on s2a > or s2 itself. But little space is needed.) >=20 > For /media being where I mounted s1 > in order to show it: >=20 > # du -Asm /media/* > 1 /media/BOOTCODE.BIN > 1 /media/CONFIG.TXT > 1 /media/FIXUP.DAT > 1 /media/FIXUP_CD.DAT > 1 /media/FIXUP_X.DAT > 1 /media/LICENCE.broadcom > 1 /media/README > 3 /media/START.ELF > 1 /media/START_CD.ELF > 4 /media/START_X.ELF > 1 /media/U-BOOT.BIN > 1 /media/fixup_db.dat > 5 /media/start_db.elf > 1 /media/ubldr.bin >=20 > So. . . > Ports based: > sysutils/rpi-firmware content > sysutils/u-boot-rpi2 content >=20 > installworld copy based: > boot/ubldr.bin copy >=20 > # du -Asm /usr/local/share/rpi-firmware = /usr/local/share/u-boot/u-boot-rpi2 > 12 /usr/local/share/rpi-firmware > 1 /usr/local/share/u-boot/u-boot-rpi2 >=20 > (I do not repeat the port instructions here.) >=20 > For /mnt being where I mounted s2a > in order to show it: >=20 > # du -Asm /mnt/*/* > 1 /mnt/boot/beastie.4th > 1 /mnt/boot/boot1.efi > 1 /mnt/boot/boot1.efifat > 1 /mnt/boot/brand-fbsd.4th > 1 /mnt/boot/brand.4th > 1 /mnt/boot/check-password.4th > 1 /mnt/boot/color.4th > 1 /mnt/boot/defaults > 1 /mnt/boot/delay.4th > 3 /mnt/boot/dtb > 1 /mnt/boot/efi.4th > 1 /mnt/boot/entropy > 1 /mnt/boot/firmware > 1 /mnt/boot/frames.4th > 1 /mnt/boot/loader.4th > 1 /mnt/boot/loader.conf > 1 /mnt/boot/loader.efi > 1 /mnt/boot/loader.help > 1 /mnt/boot/loader.rc > 1 /mnt/boot/logo-beastie.4th > 1 /mnt/boot/logo-beastiebw.4th > 1 /mnt/boot/logo-fbsdbw.4th > 1 /mnt/boot/logo-orb.4th > 1 /mnt/boot/logo-orbbw.4th > 1 /mnt/boot/menu-commands.4th > 1 /mnt/boot/menu.4th > 1 /mnt/boot/menu.rc > 1 /mnt/boot/menu.rc.sample > 1 /mnt/boot/menusets.4th > 1 /mnt/boot/modules > 1 /mnt/boot/msdos > 1 /mnt/boot/pcibios.4th > 1 /mnt/boot/screen.4th > 1 /mnt/boot/shortcuts.4th > 1 /mnt/boot/support.4th > 1 /mnt/boot/ubldr > 1 /mnt/boot/ubldr.bin > 1 /mnt/boot/version.4th > 1 /mnt/boot/zfs > 1 /mnt/etc/fstab >=20 > (I'll not list all the dtb files in the > dtb directory.) The dtb files are not needed. > # df -m /mnt > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/da4s2a 26763 5 24617 0% /mnt So, less space used in the UFS file system: # df -m /mnt Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/da4s2a 26763 2 24619 0% /mnt > (So not much space needed.) >=20 > # more /mnt/etc/fstab > /dev/da0p1 / ufs rw,noatime 1 1 > /dev/da0p2 none swap sw 0 0 >=20 > fstab used notation for the root file system > that ubldr.bin could interpret on its own. >=20 > Of course, for the /dev/da0p1 and /dev/da0p2 > notation for the USB SSD, it can be important > that other USB drives not be plugged in yet > or the paths needed might be different. >=20 > As for populating boot/ above: >=20 > Having done an installkernel and installworld locally > in order to copy selectively to the sdcard's s2a UFS > partition: >=20 > # du -Asm /usr/obj/DESTDIRs/clang-armv7-installworld/boot/* = /usr/obj/DESTDIRs/clang-armv7-installkernel/boot/dtb | more > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/beastie.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/boot1.efi > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/boot1.efifat > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/brand-fbsd.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/brand.4th > 1 = /usr/obj/DESTDIRs/clang-armv7-installworld/boot/check-password.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/color.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/defaults > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/delay.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/dtb > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/efi.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/firmware > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/frames.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/kernel > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/loader.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/loader.efi > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/loader.help > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/loader.rc > 1 = /usr/obj/DESTDIRs/clang-armv7-installworld/boot/logo-beastie.4th > 1 = /usr/obj/DESTDIRs/clang-armv7-installworld/boot/logo-beastiebw.4th > 1 = /usr/obj/DESTDIRs/clang-armv7-installworld/boot/logo-fbsdbw.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/logo-orb.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/logo-orbbw.4th > 1 = /usr/obj/DESTDIRs/clang-armv7-installworld/boot/menu-commands.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/menu.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/menu.rc > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/menusets.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/modules > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/pcibios.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/screen.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/shortcuts.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/support.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/ubldr > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/ubldr.bin > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/version.4th > 1 /usr/obj/DESTDIRs/clang-armv7-installworld/boot/zfs > 3 /usr/obj/DESTDIRs/clang-armv7-installkernel/boot/dtb /usr/obj/DESTDIRs/clang-armv7-installkernel/boot/dtb does not need to be copied to the sdcard's UFS file system. So, imagine it was not listed above. > Copy (my paths are just examples): >=20 > cp -ax /usr/obj/DESTDIRs/clang-armv7-installworld/boot /mnt/ Only the above copy is needed, not the below one. > cp -ax /usr/obj/DESTDIRs/clang-armv7-installkernel/boot/dtb /mnt/boot/ So, both dtb/ and kernel/ can be empty on the sdcard's file system. > (Updates may mean cleaning out older directory/file names.) > (A more selective copy should be possible but gets into > tracking potential changes in what files are required more > carefully.) >=20 > [For UFS the mounts presume endian matching, here little endian.] >=20 > [In my context, the USB SSD stick is on a powered hub that is > plugged into the RPI2-B V1.1 .] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat Dec 16 08: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 DE4CFEA0728 for ; Sat, 16 Dec 2017 08:00:14 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C060D7BA1A; Sat, 16 Dec 2017 08:00:14 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 065063A0D; Sat, 16 Dec 2017 08:00:13 +0000 (UTC) Date: Sat, 16 Dec 2017 08:00:13 +0000 From: Alexey Dokuchaev To: Warner Losh Cc: freebsd-arm@freebsd.org Subject: as(1) for aarch64 (Was: Re: gcc for aarch64) Message-ID: <20171216080013.GA43041@FreeBSD.org> References: <5eb49766-e5af-d89f-b4f6-a0d655a3859a@bsd.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 08:00:15 -0000 On Wed, Mar 29, 2017 at 12:22:02PM -0600, Warner Losh wrote: > The in-tree gcc compiler doesn't have any aarch64 support. Out of tree > ones should be supported though. OK, so that would explain why there is no /usr/bin/as on our ref-aarch64 boxes in the cluster. > Most developers use clang on aarch64 So does it come with assembler, is it GNU-compatible? (I was told it does: s/${AS} ${ASFLAGS}/${CC} -Wa,${ASFLAGS:ts,}/) If yes, why there is no wrapper installed as /usr/bin/as? Or it cannot be used as a drop-in replacement and users that want to call as(1) directly should install `devel/binutils' port? Thanks, ./danfe From owner-freebsd-arm@freebsd.org Sat Dec 16 13:04: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 26FD3E81CD0 for ; Sat, 16 Dec 2017 13:04:24 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E79B43FC1; Sat, 16 Dec 2017 13:04:23 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x244.google.com with SMTP id e204so5372825iof.12; Sat, 16 Dec 2017 05:04:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2rocaFtK+FXIXrZrxMa+1NSddFGWKYPmKEza3qIxW8k=; b=hvT9MV8O1JgdkqebIZRpARdJ8SiLaOoKJRLJLAi9C5zhyXg+Ic7c4OI5zHUYvuzqQL 5UyGgC+5tZtPSDnmkVOWJKyhuD1TOVI4++4j1vlH0VJX3Snnqsz2hK1ef2icC6jDwD4H KZ6PSIdCGCJ3kuOBVoGfd8l8Pb0nHXh+YGxE3n+MSettx30FKsi1VrgwLYVYNvcCgGr2 r3r89mYv+VkXMK1Mf0xObak4seAej/wcOJAl7NGWcRnfkExqgyL7eEDsdZsImQQ+ZNfR 04fCwpQmqRMXu8zun8LnfZh081RNoIBfFWM8k837XP1CrUjRrmHdkfR4o3WRonO3+DKV vJRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2rocaFtK+FXIXrZrxMa+1NSddFGWKYPmKEza3qIxW8k=; b=GtXhttXYQutGGwbR7dXwV2U2GK/zcRvaArT8Dx9rnEXi42J6IcquwrQNgDCRnEKBT1 M7+ZpXO27NDzG5z3uBWIzIgLB1jtN87++ScC89ZYBXQfn78ReXW9phhJwlsYcKwmqLwI /2Z/759d4cz8sBTINXA+k8Dm/da99VVHeaxfQiXrZ9Roj/nJX/xiHVxHdwllXUkeFNvA aTFsgZkDJsAQx6eu76bj2udQRwkJYBfIIZ0DQehHy+DbO03+rp21lup+b3C0q7mDyco4 pmpsfUVXSE+KQjFgWtlvVADp2BMVMVkgpejdpN+ST6SE1XZNFSy2Y+HbZLjDPoPVczHg KeEg== X-Gm-Message-State: AKGB3mKWpYifaDOi8Njtd7m8qaT3sQCUxOH1Nb52AYjVfvS9qxUnXCE7 olFpYJFRq1/g3mqa5jXS56l9Zpw7DJM+lJ/pHOyP3Bx7 X-Google-Smtp-Source: ACJfBovNR8luFvGYZqkMrUHZYEEkI7DA/pQNlH4+Fld3OCidL2T+dt+FzPDYR+lXniuJYO07AQtYQuVYcCrhgBLOyW0= X-Received: by 10.107.137.210 with SMTP id t79mr11716211ioi.83.1513429462773; Sat, 16 Dec 2017 05:04:22 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.131.163 with HTTP; Sat, 16 Dec 2017 05:04:02 -0800 (PST) In-Reply-To: <20171216080013.GA43041@FreeBSD.org> References: <5eb49766-e5af-d89f-b4f6-a0d655a3859a@bsd.com.br> <20171216080013.GA43041@FreeBSD.org> From: Ed Maste Date: Sat, 16 Dec 2017 08:04:02 -0500 X-Google-Sender-Auth: Ta2PP0N6pY_00EQ8lM_hGxMLnpo Message-ID: Subject: Re: as(1) for aarch64 (Was: Re: gcc for aarch64) To: Alexey Dokuchaev Cc: Warner Losh , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 13:04:24 -0000 On 16 December 2017 at 03:00, Alexey Dokuchaev wrote: > > So does it come with assembler, is it GNU-compatible? (I was told it > does: s/${AS} ${ASFLAGS}/${CC} -Wa,${ASFLAGS:ts,}/) If yes, why there > is no wrapper installed as /usr/bin/as? > > Or it cannot be used as a drop-in replacement and users that want to > call as(1) directly should install `devel/binutils' port? Thanks, Clang's integrated assembler is mostly compatible with GNU as, but there are some macro constructs etc. that it does not handle. So it's not fully a drop-in replacement. The arm64 kernel and base system assembles source files by invoking the compiler driver (as do other architectures for most, but not all, of their asm source). Users who need to invoke the assembler directly should indeed install binutils from ports or packages. From owner-freebsd-arm@freebsd.org Sat Dec 16 13:37: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 DA626E82963 for ; Sat, 16 Dec 2017 13:37:29 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B67FD63F6B; Sat, 16 Dec 2017 13:37:29 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 0A50569A3; Sat, 16 Dec 2017 13:37:29 +0000 (UTC) Date: Sat, 16 Dec 2017 13:37:29 +0000 From: Alexey Dokuchaev To: Ed Maste Cc: Warner Losh , "freebsd-arm@freebsd.org" Subject: Re: as(1) for aarch64 (Was: Re: gcc for aarch64) Message-ID: <20171216133729.GA78029@FreeBSD.org> References: <5eb49766-e5af-d89f-b4f6-a0d655a3859a@bsd.com.br> <20171216080013.GA43041@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 13:37:29 -0000 On Sat, Dec 16, 2017 at 08:04:02AM -0500, Ed Maste wrote: > Clang's integrated assembler is mostly compatible with GNU as, but > there are some macro constructs etc. that it does not handle. So it's > not fully a drop-in replacement. > > The arm64 kernel and base system assembles source files by invoking > the compiler driver (as do other architectures for most, but not all, > of their asm source). > > Users who need to invoke the assembler directly should indeed install > binutils from ports or packages. Thanks. I'll see if I can get away with Clang's integrated assembler, and fall back to `devel/binutils' if that won't work. ./danfe From owner-freebsd-arm@freebsd.org Sat Dec 16 16:04: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 A0F8EE86F6C for ; Sat, 16 Dec 2017 16:04:02 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4AEA6695D4 for ; Sat, 16 Dec 2017 16:04:01 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from [84.237.50.47] (helo=regency.nsu.ru) by mx.nsu.ru with esmtp (Exim 4.72) (envelope-from ) id 1eQEHr-0006Ja-8N for freebsd-arm@freebsd.org; Sat, 16 Dec 2017 22:22:03 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id vBGFWUOm075770 for ; Sat, 16 Dec 2017 21:32:31 +0600 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id vBGFWPJJ075711 for freebsd-arm@freebsd.org; Sat, 16 Dec 2017 22:32:25 +0700 (+07) (envelope-from danfe) Date: Sat, 16 Dec 2017 22:32:25 +0700 From: Alexey Dokuchaev To: freebsd-arm@freebsd.org Subject: How to use our stock armv7-RPI2 images with QEMU? Message-ID: <20171216153225.GA74471@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-KLMS-Rule-ID: 3 X-KLMS-Message-Action: skipped X-KLMS-AntiSpam-Status: not scanned, whitelist X-KLMS-AntiPhishing: not scanned, whitelist X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, not scanned, whitelist X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 16:04:02 -0000 Hi there, I've noticed (per qemu-system-arm -machine help) that it claims to support Raspberry Pi 2 (raspi2), so I wanted to boot one of our stock armv7-RPI2 images, but did not find recipe at https://wiki.freebsd.org/QemuRecipes, and my FreeBSD/arm knowledge is lacking. Basically I look for a fast way to setup arm6/7 VM to do some ports work. Could someone give me a hand here, and possibly update that wiki page? (It covers arm64, but not arm). Thanks, ./danfe