From owner-freebsd-arm@freebsd.org Sun Sep 2 02:52:08 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E90ECFE1969 for ; Sun, 2 Sep 2018 02:52:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-22.consmr.mail.bf2.yahoo.com (sonic312-22.consmr.mail.bf2.yahoo.com [74.6.128.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9496086E57 for ; Sun, 2 Sep 2018 02:52:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: GfaEKC8VM1kun7D6VvRoDbXkUsffgRwJFOvP2.GEbZOvuTD0af8Fz4S2HDo1uxb OfCVCI6y.uvS1DiQcYW28sqSjobJuSQnJQALMesf3IYiJ7W3RUHjPHvxUx4_Go79_dQssqDgIzuk Q99zvnsH1ErDBD4uUNjK_rfHD4S2iXy5_wCGDCqRorD7CmoRc39Q1dZuecLcavMqCWQHK3iOnTqN 4l523skGhKVHhQYij2L1fNhGIcNkinG7YhDtYO2.X_rS7lFe608Gy1g4CRveTl4wvTxSG27q5SMX VqmfQferGNSNIl4nMPd37KoGTbeqroie.opZcnEUZRdjDV0HZWWbxOaIFuSpZytM4ZNktpFUrUK9 C5fWB0JzZORN6Dl8OsNjnxkSF7Qem9gBH5mPIkNEwIdeqD9OA4i0quisjDFtpV68njan9G36qdLf l.zDFtbHQzi87PRKT0Sqahhvg_msi4vTQQNKm5fMnIcTm6MNpqzY75g_yZT3jITSfbkDpXPASd8x M78fjl97xZ1aqVGXSRs0cyfOgxRVAn6KmeAiOfcqFVua9cf0u39OxzclDUl5JQEH5UjGhBFyLQU9 V6TvSRS.SlViEGeey5EBAPhPaPvDGcZ.b8XPAbzKHBvJ_pnxzP2h923wJ6MSwq3pc_TXPOi22Txn ko3mjxJYtUU1OEheECI44NoNe1aPY84.ePsFoIaFMBdcxDeN9KTRfbUJPPLo5XUeaoY8i5QwFXOc YRPbVaNnxwlZ6mcPDKntHhjIJoM.hoIrOgsEDOpokbkDDNWAhV0d1Yv_xjCcO4iMeoO63BERVKEn p0mQWNmC40pt2o0kQZG2dE4e7VciGe_3k_Qo2962wg0i7ugeW.lLZR0Xzxt07.CVl.nq4r4mfXzD ItQ_JtQngxlOYpEWKy55tGcjTxGIgltfdmxTwEREdavExe1WHGK5DqvJJq2Zm9qekRhKSMmZRy2b B_70cOdrRTgKmgH.GINfDBIsvPSGZcfYjDlH4BwqqjFRqW49bbJxAGP._CTJjsP0pap7P7Q0HTZ7 7TvX4O80uKpM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Sun, 2 Sep 2018 02:52:01 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp423.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f75872bcf24395fac1a30782f3a9d5d9; Sun, 02 Sep 2018 02:51:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024") From: Mark Millard In-Reply-To: <20180901230233.GA42895@www.zefox.net> Date: Sat, 1 Sep 2018 19:51:54 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 02:52:08 -0000 On 2018-Sep-1, at 4:02 PM, bob prohaska wrote: > On Wed, Aug 15, 2018 at 03:55:04PM -0700, bob prohaska wrote: >>=20 >> When I started this goose chase, after zero problems with RPI2, I = thought the >> issue was arm64-related and might be of some fundamental importance. >>=20 >> Thanks to many people I now understand it's a confluence of USB and = flash memory >> artifacts, made evident by the demands of clang6. Elsewhere I noted = that I'm seeking >> "the robustness of a Mars rover, using a rack server OS on a = cellphone motherboard". >>=20 >=20 > With r338342 and > vm.pageout_oom_seq=3D"1024" > in /boot/loader.conf the RPI3 is a bit closer to a Mars Rover. > No panics, crashes or USB errors, -j4 buildworld runs to completion. > When swap usage goes over about 50% the system slows, but doesn't give = up. > There are six 1 GB swap partitions available, 3 on USB and 3 on = microSD. >=20 > Log files are at > http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/ > for the combinations tried so far. http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/2gbsd/swapscript.log shows things like: dT: 10.043s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 126 19 122 2.3 107 2034 3.3 0 0 = 0.0 29.2 da0 0 67 0 0 0.0 67 1126 2.5 0 0 = 0.0 16.6 da0f 0 59 19 122 2.3 40 909 4.7 0 0 = 0.0 14.7 da0g as well as: dT: 10.004s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 4 412 32 324 11.2 380 2945 7.9 0 0 = 0.0 80.2 mmcsd0 0 1 1 26 4.7 0 0 0.0 0 0 = 0.0 0.4 da0 4 412 32 324 11.5 380 2945 8.0 0 0 = 0.0 80.8 mmcsd0s2 2 205 15 160 10.6 190 1453 8.0 0 0 = 0.0 78.7 mmcsd0s2d 2 207 17 165 12.3 190 1491 8.0 0 0 = 0.0 78.6 mmcsd0s2e 0 0 0 0 0.0 0 1 17.5 0 0 = 0.0 0.2 mmcsd0s2a 0 0 0 0 0.0 0 1 17.6 0 0 = 0.0 0.2 ufs/rootfs 0 1 1 26 4.8 0 0 0.0 0 0 = 0.0 0.4 da0g It is not clear what partitions were in use for what types of data. da0f, da0g, mmcsd0s2d, and mmcsd0s2e: are they all swap partitions? If yes, then the the test log does not appear to be a "2gbsd" test. Ignoring such points: Are these tests using the same devices that logged errors to the console in all that prior testing? If yes: Having such errors stop is potentially interesting. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Sep 2 03:16:05 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C61DFE26E0 for ; Sun, 2 Sep 2018 03:16:05 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.cyclaero.com (ec2-18-195-62-44.eu-central-1.compute.amazonaws.com [18.195.62.44]) (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 C6BC8884FC for ; Sun, 2 Sep 2018 03:16:03 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [191.182.171.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cyclaero.com (Postfix) with ESMTPSA id 7B41089 for ; Sun, 2 Sep 2018 05:15:56 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 6B6AA1350FA87 for ; Sun, 2 Sep 2018 00:15:51 -0300 (BRT) From: "Dr. Rolf Jansen" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Kernel Panic on BBB cause by ti_adc intr Message-Id: Date: Sun, 2 Sep 2018 00:15:50 -0300 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 03:16:05 -0000 I got signal sources connected to AIN0 and AIN1 of the BBB. The signals = are divided, clipped and clamped and are guaranteed to stay in the range = of 0 to 1.8 V. Generally, the circuitry does work and the ADC readings = match very well the expectations. Only, sometimes, usually when I power on some considerable load (e.g. a = hair dryer) connected to a different AC plug, but in the same room, the = BBB bails out, giving the stack backtrace shown below. It might well be, = that a power-on spike traverses the AC electricity supply, but there is = no way that the spike after clipping and clamping would exceed said = limits. My understanding of the stack backtrace is, that somehow an interrupt is = triggered by said spike, and then it hits a bug in the interrupt = handler. It seems that an exclusive sleep mutex is locked when it is not = expected to be. This happened on FreeBSD 12.0-ALPHA3 and today also on = -ALPHA4. Question: I don't need interrupt handling in my project, since the signal changes are slow, and the changes need to be read in defined time intervals. So, is it possible to deactivate the interrupt handler of the ti_adc? Presumably then the feature of the exclusive sleep mutex on ti_adc0 = would not be challenged and therefore may continue sleeping forever. Of = course, I want continue being able of timed reading of the ADC values. Any suggestions would be greatly appreciated, since a BBB which can be = DoS'ed by powering on a hair dryer is not as useful as it could be. Best regards Rolf Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex ti_adc0 (ti_adc) r =3D 0 (0xc2277d08) locked @ = /usr/src/sys/arm/ti/ti_adc.c:508 stack backtrace: Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xd2ebeca0 FSR=3D00000005, FAR=3D00000128, spsr=3D20000013 r0 =3D00000000, r1 =3D00000003, r2 =3D00000001, r3 =3D00000000 r4 =3D00000000, r5 =3D00000000, r6 =3D00000003, r7 =3D00000016 r8 =3D00000000, r9 =3Dc2280e00, r10=3D00000021, r11=3Dd2ebed60 r12=3Dc0ace03c, ssp=3Dd2ebed30, slr=3Dc067d61c, pc =3Dc00888c0 panic: Fatal abort cpuid =3D 0 time =3D 1535844155 KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc05c7484 lr =3D 0xc0075d04 = (db_trace_self_wrapper+0x30) sp =3D 0xd2ebea80 fp =3D 0xd2ebeb98 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc0075d04 lr =3D 0xc029d60c (vpanic+0x16c) sp =3D 0xd2ebeba0 fp =3D 0xd2ebebc0 r4 =3D 0x00000100 r5 =3D 0x00000001 r6 =3D 0xc071bb22 r7 =3D 0xc0a8cfd8 vpanic() at vpanic+0x16c pc =3D 0xc029d60c lr =3D 0xc029d3ec (doadump) sp =3D 0xd2ebebc8 fp =3D 0xd2ebebcc r4 =3D 0xd2ebeca0 r5 =3D 0x00000013 r6 =3D 0x00000128 r7 =3D 0x00000005 r8 =3D 0x00000005 r9 =3D 0xd2ebeca0 r10 =3D 0x00000128 doadump() at doadump pc =3D 0xc029d3ec lr =3D 0xc05e9bb0 (abort_align) sp =3D 0xd2ebebd4 fp =3D 0xd2ebec00 r4 =3D 0xc029d3ec r5 =3D 0xd2ebebd4 abort_align() at abort_align pc =3D 0xc05e9bb0 lr =3D 0xc05e9740 (abort_handler+0x2e0) sp =3D 0xd2ebec08 fp =3D 0xd2ebec98 r4 =3D 0x00000013 r5 =3D 0x00000128 abort_handler() at abort_handler+0x2e0 pc =3D 0xc05e9740 lr =3D 0xc05c9dd4 (exception_exit) sp =3D 0xd2ebeca0 fp =3D 0xd2ebed60 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0x00000003 r7 =3D 0x00000016 r8 =3D 0x00000000 r9 =3D 0xc2280e00 r10 =3D 0x00000021 exception_exit() at exception_exit pc =3D 0xc05c9dd4 lr =3D 0xc067d61c (ti_adc_intr+0x88) sp =3D 0xd2ebed30 fp =3D 0xd2ebed60 r0 =3D 0x00000000 r1 =3D 0x00000003 r2 =3D 0x00000001 r3 =3D 0x00000000 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0x00000003 r7 =3D 0x00000016 r8 =3D 0x00000000 r9 =3D 0xc2280e00 r10 =3D 0x00000021 r12 =3D 0xc0ace03c evdev_push_event() at evdev_push_event+0x4c pc =3D 0xc00888c0 lr =3D 0xc067d61c (ti_adc_intr+0x88) sp =3D 0xd2ebed68 fp =3D 0xd2ebedd0 r4 =3D 0xd2fce800 r5 =3D 0xc2277d00 r6 =3D 0x00000000 r7 =3D 0x00000421 r8 =3D 0xc2277d18 r9 =3D 0xc2280e00 ti_adc_intr() at ti_adc_intr+0x88 pc =3D 0xc067d61c lr =3D 0xc02662fc (ithread_loop+0x1f0) sp =3D 0xd2ebedd8 fp =3D 0xd2ebee20 r4 =3D 0xd2fce800 r5 =3D 0x00000000 r6 =3D 0xd2fce844 r7 =3D 0x00000000 r8 =3D 0xc0719541 r9 =3D 0xc2280e00 r10 =3D 0x00000000 ithread_loop() at ithread_loop+0x1f0 pc =3D 0xc02662fc lr =3D 0xc0262ef8 (fork_exit+0xa0) From owner-freebsd-arm@freebsd.org Sun Sep 2 06:39:22 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68CEBFE6AB5 for ; Sun, 2 Sep 2018 06:39:22 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EE9CF8CE4D for ; Sun, 2 Sep 2018 06:39:21 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id AE51AFE6AB4; Sun, 2 Sep 2018 06:39:21 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79F64FE6AB3 for ; Sun, 2 Sep 2018 06:39:21 +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 BBC108CE4C for ; Sun, 2 Sep 2018 06:39:20 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1fwM2R-0006QR-1Y; Sun, 02 Sep 2018 09:39:11 +0300 From: Daniel Braniss Message-Id: <9EE16E32-AE1F-49DC-BF85-2AF4ECA00B0D@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: allwinner/nanopi neo boot issues Date: Sun, 2 Sep 2018 09:39:10 +0300 In-Reply-To: <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> Cc: Jakob Alvermark , "freebsd-arm@freebsd.org" To: Emmanuel Vadot References: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> <0fdbd315-f37d-e3d3-9309-612f53c4d379@alvermark.net> <8459A9BA-183A-461B-9050-3631C51218F9@cs.huji.ac.il> <474af48e-ba82-62ce-34a3-70dfc4382723@alvermark.net> <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 06:39:22 -0000 > On 1 Sep 2018, at 23:46, Emmanuel Vadot wrote: >=20 > On Sat, 1 Sep 2018 15:50:25 +0200 > Jakob Alvermark > = wrote: >=20 >> On 8/29/18 2:22 PM, Daniel Braniss wrote: >>>=20 >>>=20 >>>> On 29 Aug 2018, at 15:17, Jakob Alvermark =20 >>>> >> wrote: >>>>=20 >>>>=20 >>>> On 8/24/18 10:02 AM, Daniel Braniss wrote: >>>>>=20 >>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss =20 >>>>>> >> wrote: >>>>>>=20 >>>>>> hi, >>>>>> with the latest current r338243 no longer boots via ubldr, efi = does >>>>>> but with overlays I have to manually enter the root partition. >>>>>>=20 >>>>>> this is where it hangs via ubldr: >>>>>>=20 >>>>>> Autoboot in 8 seconds, hit [Enter] to boot or any other key to = stop >>>>>>=20 >>>>>> Loading kernel... >>>>>> /boot/kernel/kernel text=3D0x8a0950 data=3D0xae160+0x184520=20 >>>>>> syms=3D[0x4+0xa6d70+0x4+0x109f17] >>>>>> Loading configured modules... >>>>>> /boot/entropy size=3D0x1000 >>>>>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x601b >>>>>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. >>>>>> Kernel entry at 0x42400180... >>>>>> Kernel args: (null) >>>>>>=20 >>>>>> older - r337232 - boots fine, >>>>>>=20 >>>>>> any ideas where to look? >>>>> should have done an update before writing! >>>>>=20 >>>>> with the latest (and greatest) all is back to normal! >>>>> so now on to test orange pi one(h3), nanopi neo 2 (h5) and nanopi=20= >>>>> neo a64 >>>>>=20 >>>>> thanks, >>>>> danny >>>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>>=20 >>>> I am trying to get an Orange Pi R1 going, I get the same. >>>>=20 >>>> Loading kernel... >>>> /boot/kernel/kernel text=3D0x89ee40 data=3D0xae620+0x1f5ba0=20 >>>> syms=3D[0x4+0xa6d20+0x4+0x109e51] >>>> Loading configured modules... >>>> Could not load one or more modules! >>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 >>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >>>> Kernel entry at 0x42400180... >>>> Kernel args: (null) >>>>=20 >>>> This is at r338369. >>>>=20 >>>>=20 >>>=20 >>> try booting via efi; >>> make sure to copy /boot/loader.efi to = /boot/msdos/EFI/BOOT/bootaa64.efi >>> remove /boot/msdos/boot.scr >>> good luck, >>> danny >>=20 >> I tried the ALPHA4 snapshot, this happens: >>=20 >> Hit any key to stop autoboot: 0 >> switch to partitions #0, OK >> mmc0 is current device >> Scanning mmc 0:1... >> 25395 bytes read in 4 ms (6.1 MiB/s) >> Found EFI removable media binary efi/boot/bootarm.efi >> Scanning disks on usb... >> Disk usb0 not ready >> Disk usb1 not ready >> Disk usb2 not ready >> Disk usb3 not ready >> Scanning disks on mmc... >> MMC Device 1 not found >> MMC Device 2 not found >> MMC Device 3 not found >> Found 3 disks >> 508704 bytes read in 26 ms (18.7 MiB/s) >> ## Starting EFI application at 42000000 ... >> Consoles: EFI console >> failed to allocate staging area: 14 >> failed to allocate staging area >> ## Application terminated, r =3D 5 >> EFI LOAD FAILED: continuing... >>=20 >>=20 >> Tried manually loading ubldr.bin: >>=20 >> =3D> fatload mmc 0 0x42000000 ubldr.bin >> 306972 bytes read in 15 ms (19.5 MiB/s) >> =3D> go 0x42000000 >> Loading kernel... >> /boot/kernel/kernel text=3D0x85d7f0 data=3D0xaf620+0x24e1e0=20 >> syms=3D[0x4+0xa87d0+0x4+0x10c603] >> Loading configured modules... >> /boot/kernel/umodem.ko text=3D0x1bf4 text=3D0x1320 data=3D0x1080+0xf88=20= >> syms=3D[0x4+0x1070+0x4+0xbcd] >> loading required module 'ucom' >> /boot/kernel/ucom.ko text=3D0x1f8c text=3D0x2e90 data=3D0x1080+0x17bc=20= >> syms=3D[0x4+0x14f0+0x4+0xc5d] >> Could not load one or more modules! >>=20 >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 >> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >> Kernel entry at 0x42400180... >> Kernel args: (null) >>=20 >> And then it reboots... >=20 > I've just re-introduce the cache patches for u-boot as it appears that > some boards needs them (I've probably tested the wrong unpatched = u-boot > when I removed them ...) so booting with ubldr.bin should work now. confirmed working on h3/neo, both ublfr/efi. > For the EFI issue I don't really know what is happening. I think Jakob had the wrong loader.efi, by mistake I told him to copy it = as bootaa64.efi instead of bootarm.efi. danny From owner-freebsd-arm@freebsd.org Sun Sep 2 08:32:01 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC314FE8FCC for ; Sun, 2 Sep 2018 08:32:00 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 5B82D700A8 for ; Sun, 2 Sep 2018 08:32:00 +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 w828WIj8044456 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Sep 2018 01:32:19 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w828WHeX044455; Sun, 2 Sep 2018 01:32:17 -0700 (PDT) (envelope-from fbsd) Date: Sun, 2 Sep 2018 01:32:17 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024") Message-ID: <20180902083217.GA44384@www.zefox.net> References: <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 08:32:01 -0000 On Sat, Sep 01, 2018 at 07:51:54PM -0700, Mark Millard wrote: > > > On 2018-Sep-1, at 4:02 PM, bob prohaska wrote: > > > On Wed, Aug 15, 2018 at 03:55:04PM -0700, bob prohaska wrote: > >> > >> When I started this goose chase, after zero problems with RPI2, I thought the > >> issue was arm64-related and might be of some fundamental importance. > >> > >> Thanks to many people I now understand it's a confluence of USB and flash memory > >> artifacts, made evident by the demands of clang6. Elsewhere I noted that I'm seeking > >> "the robustness of a Mars rover, using a rack server OS on a cellphone motherboard". > >> > > > > With r338342 and > > vm.pageout_oom_seq="1024" > > in /boot/loader.conf the RPI3 is a bit closer to a Mars Rover. > > No panics, crashes or USB errors, -j4 buildworld runs to completion. > > When swap usage goes over about 50% the system slows, but doesn't give up. > > There are six 1 GB swap partitions available, 3 on USB and 3 on microSD. > > > > Log files are at > > http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/ > > for the combinations tried so far. > > http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/2gbsd/swapscript.log > > shows things like: > > dT: 10.043s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name > 0 126 19 122 2.3 107 2034 3.3 0 0 0.0 29.2 da0 > 0 67 0 0 0.0 67 1126 2.5 0 0 0.0 16.6 da0f > 0 59 19 122 2.3 40 909 4.7 0 0 0.0 14.7 da0g > > as well as: > > dT: 10.004s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name > 4 412 32 324 11.2 380 2945 7.9 0 0 0.0 80.2 mmcsd0 > 0 1 1 26 4.7 0 0 0.0 0 0 0.0 0.4 da0 > 4 412 32 324 11.5 380 2945 8.0 0 0 0.0 80.8 mmcsd0s2 > 2 205 15 160 10.6 190 1453 8.0 0 0 0.0 78.7 mmcsd0s2d > 2 207 17 165 12.3 190 1491 8.0 0 0 0.0 78.6 mmcsd0s2e > 0 0 0 0 0.0 0 1 17.5 0 0 0.0 0.2 mmcsd0s2a > 0 0 0 0 0.0 0 1 17.6 0 0 0.0 0.2 ufs/rootfs > 0 1 1 26 4.8 0 0 0.0 0 0 0.0 0.4 da0g > > It is not clear what partitions were in use for what types of > data. da0f, da0g, mmcsd0s2d, and mmcsd0s2e: are they all > swap partitions? If yes, then the the test log does not appear > to be a "2gbsd" test. > The swap partitions are identified in the swapinfo data following the gstat and date output, in this case mmcsd0s2d and -e. /var is on da0e, /tmp is on da0f and /usr is on da0g. I do apologize, that was ambiguous. It's in the readme for that revision number now. > > Ignoring such points: Are these tests using the same devices that logged > errors to the console in all that prior testing? > > If yes: Having such errors stop is potentially interesting. > Yes, this is the same pair of devices which produced the flood of USB errors when either deliberately run out of swap or used with OOMA turned off. The USB flash drive is a Sandisk SDCZ800-064G, nominally a "USB3.1" device. It's quite clear that I/O congestion badly affects performance, but I'm not convinced it's exclusively swap I/O that causes trouble. Sometimes it looks as if traffic to /usr gums up the works and takes minutes to unjam. In any case, the fact that the system rights itself and keeps working is encouraging. It's also interesting, though probably not useful, to note that 4 GB of swap seems to cause no trouble, at least in this configuration. I haven't tried 6 GB yet. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Sun Sep 2 13:57:28 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15096FF011D for ; Sun, 2 Sep 2018 13:57:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7642079CDC for ; Sun, 2 Sep 2018 13:57:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: tnLiZ2EVM1mmDzYY81DE4yVdofdwUfx8QzTCcGRsdDC.vv5111L.HPykBLeEOQ2 VSvIAhb_k20abXI0cCJ.r40P7ahRkdWY0F..pkUfkHOdTDave7PL8Y2P11kGuVG9POrRox3En3NZ 5NNoS8_8czgmc8NC8XsXCIjmTuMIAWCBqAGleZB9aXVUHMoX5.2R1N4l5yz2dU2eAraXTCpsyy1N M0aecjZnvtwK6Enn7q0BKfZzgNE2zaqbOff3fIKK.vLJgzv3dzyIRqmunQDbbNqlxqtLAVF2d5Jv K.Mjp5JsTO7jDY5eFnR8JzNKDOe2WKMO_7ea_v6XIWc0PW6cEzzY7ZjVNCXcOJs5sUedoTsigw8P HCzpzXfcnuqL9K0FwEBW9P322JbxZrT5dhK4pMBsDTbbNgRCU.8bqHzzg.pgge7ipCj4jEI5S1CE r3vtAVau9nDrDj8jJOZ.KhGuxDHvScLsYzbbyyrapp6CD9bljmlcqkRQUGezVVDkVPuLlJ52Gtjo eFJkEWtTH_FUxCJmzdvzIo7nZcf_erL5gMeZmARGD3lmYUxKdNNfARYRu6QQ.9Im4j5V5tDgX4nW nD5VfODjcnecGlCaYK4sCZKFOT4YmAtWmaxF0bz3jLo6PUK8yFCLzYlhe7PRzwqdglKDcDSFWktd UKuJUuSjOLMZPDxcDyv9VAXbW8B5TOfWZL46sjZva5OYJi.g6n5U3DS8m.EjiMcqNbLb0CCkgNy6 8b4IpgHMn7IByv_.gaNlJZv6FeH1znZtjjI2213NyJeLIOD64ldmjo.hwJ_5UG4sE3McgJJ7S5sG _wRpwdgnXqS1OYBpaowv1Embn7xWzfsaFF.VMSLd2KO3OekVBhOppnR_egHZAZcbSGV1wFhKWS7Q J52CJ7iSGTQo2qipRgXgDE4zR9WuY9DakZRay.NGBO9Htq4bE.6Bcu7IBq9ntauPbTjWDj3xbVNB ujSLlhaCjerZn9_H159CS8xjVOBkOiT5tvNubQ8EuBWle0ig2Fa_8Auncr68COuncFdoUtDmO9q. 8Sr77Xe0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sun, 2 Sep 2018 13:57:19 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp408.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 24b0006e88a42eaaff8011be1d24ecff; Sun, 02 Sep 2018 13:57:16 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024") From: Mark Millard In-Reply-To: <20180902083217.GA44384@www.zefox.net> Date: Sun, 2 Sep 2018 06:57:15 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <6B8E28DC-075D-4829-9BEA-F36DDB1E2A25@yahoo.com> References: <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <20180902083217.GA44384@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 13:57:28 -0000 Was this with or without (presuming a ufs file system): tunefs: trim: (-t) enabled ? If enabled, with or without: sysctl vfs.ffs.dotrimcons=1 In other words: was "consolidation of TRIM / BIO_DELETE commands to the UFS/FFS filesystem" enabled? Disabled? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Sep 2 15:09:40 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64251FF1A7E for ; Sun, 2 Sep 2018 15:09:40 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D1B9B7BEE4 for ; Sun, 2 Sep 2018 15:09:39 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 3021ee76-aec2-11e8-a747-09a40681ccbf X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 3021ee76-aec2-11e8-a747-09a40681ccbf; Sun, 02 Sep 2018 15:09:30 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w82F9SbP024747; Sun, 2 Sep 2018 09:09:28 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1535900968.9486.5.camel@freebsd.org> Subject: Re: Kernel Panic on BBB cause by ti_adc intr From: Ian Lepore To: "Dr. Rolf Jansen" , freebsd-arm@freebsd.org Date: Sun, 02 Sep 2018 09:09:28 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 15:09:40 -0000 On Sun, 2018-09-02 at 00:15 -0300, Dr. Rolf Jansen wrote: > I got signal sources connected to AIN0 and AIN1 of the BBB. The > signals are divided, clipped and clamped and are guaranteed to stay > in the range of 0 to 1.8 V. Generally, the circuitry does work and > the ADC readings match very well the expectations. > > Only, sometimes, usually when I power on some considerable load (e.g. > a hair dryer) connected to a different AC plug, but in the same room, > the BBB bails out, giving the stack backtrace shown below. It might > well be, that a power-on spike traverses the AC electricity supply, > but there is no way that the spike after clipping and clamping would > exceed said limits. > > My understanding of the stack backtrace is, that somehow an interrupt > is triggered by said spike, and then it hits a bug in the interrupt > handler. It seems that an exclusive sleep mutex is locked when it is > not expected to be. This happened on FreeBSD 12.0-ALPHA3 and today > also on -ALPHA4. > > Question: > >    I don't need interrupt handling in my project, since the signal >    changes are slow, and the changes need to be read in defined >    time intervals. So, is it possible to deactivate the interrupt >    handler of the ti_adc? > > Presumably then the feature of the exclusive sleep mutex on ti_adc0 > would not be challenged and therefore may continue sleeping forever. > Of course, I want continue being able of timed reading of the ADC > values. > > Any suggestions would be greatly appreciated, since a BBB which can > be DoS'ed by powering on a hair dryer is not as useful as it could > be. > > Best regards > > Rolf > > > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex ti_adc0 (ti_adc) r = 0 (0xc2277d08) locked @ > /usr/src/sys/arm/ti/ti_adc.c:508 > stack backtrace: > Fatal kernel mode data abort: 'Translation Fault (L1)' on read > trapframe: 0xd2ebeca0 > FSR=00000005, FAR=00000128, spsr=20000013 > r0 =00000000, r1 =00000003, r2 =00000001, r3 =00000000 > r4 =00000000, r5 =00000000, r6 =00000003, r7 =00000016 > r8 =00000000, r9 =c2280e00, r10=00000021, r11=d2ebed60 > r12=c0ace03c, ssp=d2ebed30, slr=c067d61c, pc =c00888c0 > > panic: Fatal abort > cpuid = 0 > time = 1535844155 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc05c7484  lr = 0xc0075d04 (db_trace_self_wrapper+0x30) > sp = 0xd2ebea80  fp = 0xd2ebeb98 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc0075d04  lr = 0xc029d60c (vpanic+0x16c) > sp = 0xd2ebeba0  fp = 0xd2ebebc0 > r4 = 0x00000100  r5 = 0x00000001 > r6 = 0xc071bb22  r7 = 0xc0a8cfd8 > vpanic() at vpanic+0x16c > pc = 0xc029d60c  lr = 0xc029d3ec (doadump) > sp = 0xd2ebebc8  fp = 0xd2ebebcc > r4 = 0xd2ebeca0  r5 = 0x00000013 > r6 = 0x00000128  r7 = 0x00000005 > r8 = 0x00000005  r9 = 0xd2ebeca0 > r10 = 0x00000128 > doadump() at doadump > pc = 0xc029d3ec  lr = 0xc05e9bb0 (abort_align) > sp = 0xd2ebebd4  fp = 0xd2ebec00 > r4 = 0xc029d3ec  r5 = 0xd2ebebd4 > abort_align() at abort_align > pc = 0xc05e9bb0  lr = 0xc05e9740 (abort_handler+0x2e0) > sp = 0xd2ebec08  fp = 0xd2ebec98 > r4 = 0x00000013  r5 = 0x00000128 > abort_handler() at abort_handler+0x2e0 > pc = 0xc05e9740  lr = 0xc05c9dd4 (exception_exit) > sp = 0xd2ebeca0  fp = 0xd2ebed60 > r4 = 0x00000000  r5 = 0x00000000 > r6 = 0x00000003  r7 = 0x00000016 > r8 = 0x00000000  r9 = 0xc2280e00 > r10 = 0x00000021 > exception_exit() at exception_exit > pc = 0xc05c9dd4  lr = 0xc067d61c (ti_adc_intr+0x88) > sp = 0xd2ebed30  fp = 0xd2ebed60 > r0 = 0x00000000  r1 = 0x00000003 > r2 = 0x00000001  r3 = 0x00000000 > r4 = 0x00000000  r5 = 0x00000000 > r6 = 0x00000003  r7 = 0x00000016 > r8 = 0x00000000  r9 = 0xc2280e00 > r10 = 0x00000021 r12 = 0xc0ace03c > evdev_push_event() at evdev_push_event+0x4c > pc = 0xc00888c0  lr = 0xc067d61c (ti_adc_intr+0x88) > sp = 0xd2ebed68  fp = 0xd2ebedd0 > r4 = 0xd2fce800  r5 = 0xc2277d00 > r6 = 0x00000000  r7 = 0x00000421 > r8 = 0xc2277d18  r9 = 0xc2280e00 > ti_adc_intr() at ti_adc_intr+0x88 > pc = 0xc067d61c  lr = 0xc02662fc (ithread_loop+0x1f0) > sp = 0xd2ebedd8  fp = 0xd2ebee20 > r4 = 0xd2fce800  r5 = 0x00000000 > r6 = 0xd2fce844  r7 = 0x00000000 > r8 = 0xc0719541  r9 = 0xc2280e00 > r10 = 0x00000000 > ithread_loop() at ithread_loop+0x1f0 > pc = 0xc02662fc  lr = 0xc0262ef8 (fork_exit+0xa0) That's a strange exception stack, with lots of registers containing zeroes at exception time that were non-zero in the prior stack frame. It makes me think something has overwritten the stack with garbage data. When I look at ti_adc_tsc_read_data() it has a stack-allocated data array with 16 elements, and a loop that could load more than 16 elements into that array (ADC_FIFO_COUNT_MSK is 0x7f), that seems like trouble. You said you don't need interrupts, does that mean you're reading the values via sysctl and aren't using the EVDEV stuff? If so, you might be able to quickly work around the panic by building a custom kernel using 'nooption EVDEV_SUPPORT'. -- Ian From owner-freebsd-arm@freebsd.org Sun Sep 2 15:14:21 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A4E5FF1D5E for ; Sun, 2 Sep 2018 15:14:21 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CE4AB7C271 for ; Sun, 2 Sep 2018 15:14:20 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: by mailman.ysv.freebsd.org (Postfix) id 90AB1FF1D5D; Sun, 2 Sep 2018 15:14:20 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6EC4DFF1D5C for ; Sun, 2 Sep 2018 15:14:20 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 EC1677C270 for ; Sun, 2 Sep 2018 15:14:19 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-42bc70d5.06-431-73746f70.bbcust.telenor.se ([213.112.188.66] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fwU4p-000G0C-FP; Sun, 02 Sep 2018 17:14:11 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ToNz6n3j4FY+iEf9ac+DgsQC67Ob3uiz4rhEQ3j2Wnc=; b=TJ/RRaCrv5q+CJSV7vidslv3L6 ykzrOS1dnRUFBtCk5/mXUaryHLXrUFgrIiMKj4Tv91lLWR4vdtppUpqOXZNX6BLN+5MlVj7Wb+ke8 m8fDHnW4BQxgDiuWbA/L6p37HLp32LSf5eBo4ETgyEMSb3t6mELeNXiHDORMb2w7H1G1pUz1WbK7/ n4FgKYOP88rGemdJY6Squ54xnrbkEqLpvOVLSUXLmxdWrP05aeKDGNpKXuIqjscG3PtGgu07Xe/Zt ztuM6m8sEhj+xhWVsYNSAeaW06p8WETkYC+svIH4zvKlBP2VEtUqkMQv8KFlZJqP9Hj2hM2mq1V+u iUCBhOaw==; Received: from [192.168.67.33] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fwU4p-0002AW-0K; Sun, 02 Sep 2018 17:14:11 +0200 Subject: Re: allwinner/nanopi neo boot issues To: Emmanuel Vadot Cc: Daniel Braniss , "freebsd-arm@freebsd.org" References: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> <0fdbd315-f37d-e3d3-9309-612f53c4d379@alvermark.net> <8459A9BA-183A-461B-9050-3631C51218F9@cs.huji.ac.il> <474af48e-ba82-62ce-34a3-70dfc4382723@alvermark.net> <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> From: Jakob Alvermark Message-ID: <03d4cb0a-c218-a186-936d-765261da2775@alvermark.net> Date: Sun, 2 Sep 2018 17:14:10 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 15:14:21 -0000 On 9/1/18 10:46 PM, Emmanuel Vadot wrote: > On Sat, 1 Sep 2018 15:50:25 +0200 > Jakob Alvermark wrote: > >> On 8/29/18 2:22 PM, Daniel Braniss wrote: >>> >>>> On 29 Aug 2018, at 15:17, Jakob Alvermark >>> > wrote: >>>> >>>> >>>> On 8/24/18 10:02 AM, Daniel Braniss wrote: >>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss >>>>> > wrote: >>>>>> >>>>>> hi, >>>>>> with the latest current r338243 no longer boots via ubldr, efi does >>>>>> but with overlays I have to manually enter the root partition. >>>>>> >>>>>> this is where it hangs via ubldr: >>>>>> >>>>>> Autoboot in 8 seconds, hit [Enter] to boot or any other key to stop >>>>>> >>>>>> Loading kernel... >>>>>> /boot/kernel/kernel text=0x8a0950 data=0xae160+0x184520 >>>>>> syms=[0x4+0xa6d70+0x4+0x109f17] >>>>>> Loading configured modules... >>>>>> /boot/entropy size=0x1000 >>>>>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=0x601b >>>>>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. >>>>>> Kernel entry at 0x42400180... >>>>>> Kernel args: (null) >>>>>> >>>>>> older - r337232 - boots fine, >>>>>> >>>>>> any ideas where to look? >>>>> should have done an update before writing! >>>>> >>>>> with the latest (and greatest) all is back to normal! >>>>> so now on to test orange pi one(h3), nanopi neo 2 (h5) and nanopi >>>>> neo a64 >>>>> >>>>> thanks, >>>>> danny >>>> >>>> Hi, >>>> >>>> >>>> I am trying to get an Orange Pi R1 going, I get the same. >>>> >>>> Loading kernel... >>>> /boot/kernel/kernel text=0x89ee40 data=0xae620+0x1f5ba0 >>>> syms=[0x4+0xa6d20+0x4+0x109e51] >>>> Loading configured modules... >>>> Could not load one or more modules! >>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333 >>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >>>> Kernel entry at 0x42400180... >>>> Kernel args: (null) >>>> >>>> This is at r338369. >>>> >>>> >>> try booting via efi; >>> make sure to copy /boot/loader.efi to /boot/msdos/EFI/BOOT/bootaa64.efi >>> remove /boot/msdos/boot.scr >>> good luck, >>> danny >> I tried the ALPHA4 snapshot, this happens: >> >> Hit any key to stop autoboot:  0 >> switch to partitions #0, OK >> mmc0 is current device >> Scanning mmc 0:1... >> 25395 bytes read in 4 ms (6.1 MiB/s) >> Found EFI removable media binary efi/boot/bootarm.efi >> Scanning disks on usb... >> Disk usb0 not ready >> Disk usb1 not ready >> Disk usb2 not ready >> Disk usb3 not ready >> Scanning disks on mmc... >> MMC Device 1 not found >> MMC Device 2 not found >> MMC Device 3 not found >> Found 3 disks >> 508704 bytes read in 26 ms (18.7 MiB/s) >> ## Starting EFI application at 42000000 ... >> Consoles: EFI console >> failed to allocate staging area: 14 >> failed to allocate staging area >> ## Application terminated, r = 5 >> EFI LOAD FAILED: continuing... >> >> >> Tried manually loading ubldr.bin: >> >> => fatload mmc 0 0x42000000 ubldr.bin >> 306972 bytes read in 15 ms (19.5 MiB/s) >> => go 0x42000000 >> Loading kernel... >> /boot/kernel/kernel text=0x85d7f0 data=0xaf620+0x24e1e0 >> syms=[0x4+0xa87d0+0x4+0x10c603] >> Loading configured modules... >> /boot/kernel/umodem.ko text=0x1bf4 text=0x1320 data=0x1080+0xf88 >> syms=[0x4+0x1070+0x4+0xbcd] >> loading required module 'ucom' >> /boot/kernel/ucom.ko text=0x1f8c text=0x2e90 data=0x1080+0x17bc >> syms=[0x4+0x14f0+0x4+0xc5d] >> Could not load one or more modules! >> >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333 >> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >> Kernel entry at 0x42400180... >> Kernel args: (null) >> >> And then it reboots... > I've just re-introduce the cache patches for u-boot as it appears that > some boards needs them (I've probably tested the wrong unpatched u-boot > when I removed them ...) so booting with ubldr.bin should work now. > For the EFI issue I don't really know what is happening. Thanks! With the updated U-boot it now boots with ubldr.bin. How can I make it do this automatically? Also, the network interface does not attach: awg0: mem 0x1c30000-0x1c3ffff irq 22 on simplebus0 awg0: soft reset timed out device_attach: awg0 attach returned 60 Jakob From owner-freebsd-arm@freebsd.org Sun Sep 2 15:24:49 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C086FF2015 for ; Sun, 2 Sep 2018 15:24:49 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 860E87C5E5 for ; Sun, 2 Sep 2018 15:24:48 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3A086FF2014; Sun, 2 Sep 2018 15:24:48 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12FDDFF2011 for ; Sun, 2 Sep 2018 15:24:48 +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 872D17C5E4 for ; Sun, 2 Sep 2018 15:24:47 +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 7ec32d3b; Sun, 2 Sep 2018 17:24:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=Rn+yuJPSLmxgl+agbrXOC8cuX8U=; b=jyvQyyr+8EEHsYRXv+AlV0psQk5v A5UKAuROU+k5RoNo0Vnf22W7/BSGstgJpi6egYqYsaXaiXq+oyu69wa6fCgH3eU+ wCNq4iQv4bkSGcd9TcFtnhkvsgjBL3vyKSXUh/sy5m+kmOx4NceS4P8Akd1aFFOP cRNF8q9td5fzMgw= 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=hBT4nhcNJxotRyjYrkIlt8CArLw0ma6aYe9v8pZ8NCVe21MVKKyunCsz euIerY65wmv+4h6PzYQ6ece+cIuMy0rNmbxDRj/JuWb8VzvvnOlHsIlkQCffasYk RQg1pA6qkueLgdvoVgSYwYVPhW2EfKRJ7RK50bq7B8L8jTHdZGk= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 016977de TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sun, 2 Sep 2018 17:24:44 +0200 (CEST) Date: Sun, 2 Sep 2018 17:24:44 +0200 From: Emmanuel Vadot To: Jakob Alvermark Cc: Daniel Braniss , "freebsd-arm@freebsd.org" Subject: Re: allwinner/nanopi neo boot issues Message-Id: <20180902172444.c4911c8c65a99a7d5e9fe8fa@bidouilliste.com> In-Reply-To: <03d4cb0a-c218-a186-936d-765261da2775@alvermark.net> References: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> <0fdbd315-f37d-e3d3-9309-612f53c4d379@alvermark.net> <8459A9BA-183A-461B-9050-3631C51218F9@cs.huji.ac.il> <474af48e-ba82-62ce-34a3-70dfc4382723@alvermark.net> <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> <03d4cb0a-c218-a186-936d-765261da2775@alvermark.net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; 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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 15:24:49 -0000 On Sun, 2 Sep 2018 17:14:10 +0200 Jakob Alvermark wrote: > On 9/1/18 10:46 PM, Emmanuel Vadot wrote: > > On Sat, 1 Sep 2018 15:50:25 +0200 > > Jakob Alvermark wrote: > > > >> On 8/29/18 2:22 PM, Daniel Braniss wrote: > >>> > >>>> On 29 Aug 2018, at 15:17, Jakob Alvermark >>>> > wrote: > >>>> > >>>> > >>>> On 8/24/18 10:02 AM, Daniel Braniss wrote: > >>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss >>>>>> > wrote: > >>>>>> > >>>>>> hi, > >>>>>> with the latest current r338243 no longer boots via ubldr, efi does > >>>>>> but with overlays I have to manually enter the root partition. > >>>>>> > >>>>>> this is where it hangs via ubldr: > >>>>>> > >>>>>> Autoboot in 8 seconds, hit [Enter] to boot or any other key to stop > >>>>>> > >>>>>> Loading kernel... > >>>>>> /boot/kernel/kernel text=3D0x8a0950 data=3D0xae160+0x184520 > >>>>>> syms=3D[0x4+0xa6d70+0x4+0x109f17] > >>>>>> Loading configured modules... > >>>>>> /boot/entropy size=3D0x1000 > >>>>>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x601b > >>>>>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. > >>>>>> Kernel entry at 0x42400180... > >>>>>> Kernel args: (null) > >>>>>> > >>>>>> older - r337232 - boots fine, > >>>>>> > >>>>>> any ideas where to look? > >>>>> should have done an update before writing! > >>>>> > >>>>> with the latest (and greatest) all is back to normal! > >>>>> so now on to test orange pi one(h3), nanopi neo 2 (h5) and nanopi > >>>>> neo a64 > >>>>> > >>>>> thanks, > >>>>> danny > >>>> > >>>> Hi, > >>>> > >>>> > >>>> I am trying to get an Orange Pi R1 going, I get the same. > >>>> > >>>> Loading kernel... > >>>> /boot/kernel/kernel text=3D0x89ee40 data=3D0xae620+0x1f5ba0 > >>>> syms=3D[0x4+0xa6d20+0x4+0x109e51] > >>>> Loading configured modules... > >>>> Could not load one or more modules! > >>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 > >>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. > >>>> Kernel entry at 0x42400180... > >>>> Kernel args: (null) > >>>> > >>>> This is at r338369. > >>>> > >>>> > >>> try booting via efi; > >>> make sure to copy /boot/loader.efi to /boot/msdos/EFI/BOOT/bootaa64.e= fi > >>> remove /boot/msdos/boot.scr > >>> good luck, > >>> danny > >> I tried the ALPHA4 snapshot, this happens: > >> > >> Hit any key to stop autoboot:=A0 0 > >> switch to partitions #0, OK > >> mmc0 is current device > >> Scanning mmc 0:1... > >> 25395 bytes read in 4 ms (6.1 MiB/s) > >> Found EFI removable media binary efi/boot/bootarm.efi > >> Scanning disks on usb... > >> Disk usb0 not ready > >> Disk usb1 not ready > >> Disk usb2 not ready > >> Disk usb3 not ready > >> Scanning disks on mmc... > >> MMC Device 1 not found > >> MMC Device 2 not found > >> MMC Device 3 not found > >> Found 3 disks > >> 508704 bytes read in 26 ms (18.7 MiB/s) > >> ## Starting EFI application at 42000000 ... > >> Consoles: EFI console > >> failed to allocate staging area: 14 > >> failed to allocate staging area > >> ## Application terminated, r =3D 5 > >> EFI LOAD FAILED: continuing... > >> > >> > >> Tried manually loading ubldr.bin: > >> > >> =3D> fatload mmc 0 0x42000000 ubldr.bin > >> 306972 bytes read in 15 ms (19.5 MiB/s) > >> =3D> go 0x42000000 > >> Loading kernel... > >> /boot/kernel/kernel text=3D0x85d7f0 data=3D0xaf620+0x24e1e0 > >> syms=3D[0x4+0xa87d0+0x4+0x10c603] > >> Loading configured modules... > >> /boot/kernel/umodem.ko text=3D0x1bf4 text=3D0x1320 data=3D0x1080+0xf88 > >> syms=3D[0x4+0x1070+0x4+0xbcd] > >> loading required module 'ucom' > >> /boot/kernel/ucom.ko text=3D0x1f8c text=3D0x2e90 data=3D0x1080+0x17bc > >> syms=3D[0x4+0x14f0+0x4+0xc5d] > >> Could not load one or more modules! > >> > >> Hit [Enter] to boot immediately, or any other key for command prompt. > >> Booting [/boot/kernel/kernel]... > >> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 > >> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. > >> Kernel entry at 0x42400180... > >> Kernel args: (null) > >> > >> And then it reboots... > > I've just re-introduce the cache patches for u-boot as it appears that > > some boards needs them (I've probably tested the wrong unpatched u-boot > > when I removed them ...) so booting with ubldr.bin should work now. > > For the EFI issue I don't really know what is happening. >=20 >=20 > Thanks! With the updated U-boot it now boots with ubldr.bin. >=20 > How can I make it do this automatically? If you copy the boot.scr file from the port/package to the root of the fat partition this will load ubldr.bin directly. I'm more interested to debug the efi problem, I'll try on a H2 board. > Also, the network interface does not attach: >=20 > awg0: mem 0x1c30000-0x1c3ffff irq 22 on=20 > simplebus0 > awg0: soft reset timed out > device_attach: awg0 attach returned 60 Yes there is a problem on some boards when the cable isn't connected, someone (tm) will need to debug that one day. > Jakob --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sun Sep 2 15:27:00 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4AE8FF20F4 for ; Sun, 2 Sep 2018 15:27:00 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 08C697C6AF for ; Sun, 2 Sep 2018 15:26:59 +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 w82FRHcs045928 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Sep 2018 08:27:18 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w82FRHx9045927; Sun, 2 Sep 2018 08:27:17 -0700 (PDT) (envelope-from fbsd) Date: Sun, 2 Sep 2018 08:27:17 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024") Message-ID: <20180902152717.GB44384@www.zefox.net> References: <20180814014226.GA50013@www.zefox.net> <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <20180902083217.GA44384@www.zefox.net> <6B8E28DC-075D-4829-9BEA-F36DDB1E2A25@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6B8E28DC-075D-4829-9BEA-F36DDB1E2A25@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 15:27:00 -0000 On Sun, Sep 02, 2018 at 06:57:15AM -0700, Mark Millard wrote: > Was this with or without (presuming a ufs file system): > > tunefs: trim: (-t) enabled > > ? If enabled, with or without: > > sysctl vfs.ffs.dotrimcons=1 > > In other words: was "consolidation of TRIM / BIO_DELETE > commands to the UFS/FFS filesystem" enabled? Disabled? > No, it was not. By all accounts TRIM enabling won't affect USB2.0 devices, and it's fairly clear the bottleneck is in USB, not microSD. Trim is enabled for mmcsd0s2a, but sysctl vfs.ffs.dotrimcons=1 hasn't been invoked. I'll turn it on later, to check for bad side effects, but there's no obvious reason to think it'll help. At the moment the diskscript is reporting: dT: 10.005s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 0 0 0 0 0.0 0 9 5.2 0 0 0.0 0.2 mmcsd0 10 0 0 0 0.0 0 2 13790 0 0 0.0 89.9 da0 0 0 0 0 0.0 0 2 3.9 0 0 0.0 0.1 mmcsd0s2b 0 0 0 0 0.0 0 9 5.2 0 0 0.0 0.2 mmcsd0s2 9 0 0 0 0.0 0 2 13790 0 0 0.0 89.9 da0b Sun Sep 2 08:17:14 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 494352 554224 47% /dev/mmcsd0s2b 1048576 478860 569716 46% Total 2097152 973212 1123940 46% Sep 2 08:14:38 www kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1649558, size: 4096 Sep 2 08:14:38 www kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1654590, size: 16384 Top is reporting ~10-50% idle time, not surprising given delays writing to da0b. I was hoping the pager might favor microSD given the much faster I/O times, but evidently not. Seems to be a strict round-robin division of labor. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Sun Sep 2 15:40:52 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88C04FF26A4 for ; Sun, 2 Sep 2018 15:40:52 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.cyclaero.com (ec2-18-195-62-44.eu-central-1.compute.amazonaws.com [18.195.62.44]) (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 0856A7CF90; Sun, 2 Sep 2018 15:40:51 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [191.182.171.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cyclaero.com (Postfix) with ESMTPSA id 8C69121; Sun, 2 Sep 2018 17:40:49 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 4656A1350FA87; Sun, 2 Sep 2018 12:40:45 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Kernel Panic on BBB cause by ti_adc intr From: "Dr. Rolf Jansen" In-Reply-To: <1535900968.9486.5.camel@freebsd.org> Date: Sun, 2 Sep 2018 12:40:44 -0300 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <09B4DAE6-4021-4D77-8D74-6E112EE5E9E8@obsigna.com> References: <1535900968.9486.5.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 15:40:52 -0000 > Am 02.09.2018 um 12:09 schrieb Ian Lepore : >=20 > On Sun, 2018-09-02 at 00:15 -0300, Dr. Rolf Jansen wrote: >> I got signal sources connected to AIN0 and AIN1 of the BBB. The >> signals are divided, clipped and clamped and are guaranteed to stay >> in the range of 0 to 1.8 V. Generally, the circuitry does work and >> the ADC readings match very well the expectations. >>=20 >> Only, sometimes, usually when I power on some considerable load (e.g. >> a hair dryer) connected to a different AC plug, but in the same room, >> the BBB bails out, giving the stack backtrace shown below. It might >> well be, that a power-on spike traverses the AC electricity supply, >> but there is no way that the spike after clipping and clamping would >> exceed said limits. >>=20 >> My understanding of the stack backtrace is, that somehow an interrupt >> is triggered by said spike, and then it hits a bug in the interrupt >> handler. It seems that an exclusive sleep mutex is locked when it is >> not expected to be. This happened on FreeBSD 12.0-ALPHA3 and today >> also on -ALPHA4. >>=20 >> Question: >>=20 >> I don't need interrupt handling in my project, since the signal >> changes are slow, and the changes need to be read in defined >> time intervals. So, is it possible to deactivate the interrupt >> handler of the ti_adc? >>=20 >> Presumably then the feature of the exclusive sleep mutex on ti_adc0 >> would not be challenged and therefore may continue sleeping forever. >> Of course, I want continue being able of timed reading of the ADC >> values. >>=20 >> Any suggestions would be greatly appreciated, since a BBB which can >> be DoS'ed by powering on a hair dryer is not as useful as it could >> be. >>=20 >> Best regards >>=20 >> Rolf >>=20 >>=20 >> Kernel page fault with the following non-sleepable locks held: >> exclusive sleep mutex ti_adc0 (ti_adc) r =3D 0 (0xc2277d08) locked @ >> /usr/src/sys/arm/ti/ti_adc.c:508 >> stack backtrace: >> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> trapframe: 0xd2ebeca0 >> FSR=3D00000005, FAR=3D00000128, spsr=3D20000013 >> r0 =3D00000000, r1 =3D00000003, r2 =3D00000001, r3 =3D00000000 >> r4 =3D00000000, r5 =3D00000000, r6 =3D00000003, r7 =3D00000016 >> r8 =3D00000000, r9 =3Dc2280e00, r10=3D00000021, r11=3Dd2ebed60 >> r12=3Dc0ace03c, ssp=3Dd2ebed30, slr=3Dc067d61c, pc =3Dc00888c0 >>=20 >> panic: Fatal abort >> cpuid =3D 0 >> time =3D 1535844155 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self >> pc =3D 0xc05c7484 lr =3D 0xc0075d04 = (db_trace_self_wrapper+0x30) >> sp =3D 0xd2ebea80 fp =3D 0xd2ebeb98 >> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >> pc =3D 0xc0075d04 lr =3D 0xc029d60c (vpanic+0x16c) >> sp =3D 0xd2ebeba0 fp =3D 0xd2ebebc0 >> r4 =3D 0x00000100 r5 =3D 0x00000001 >> r6 =3D 0xc071bb22 r7 =3D 0xc0a8cfd8 >> vpanic() at vpanic+0x16c >> pc =3D 0xc029d60c lr =3D 0xc029d3ec (doadump) >> sp =3D 0xd2ebebc8 fp =3D 0xd2ebebcc >> r4 =3D 0xd2ebeca0 r5 =3D 0x00000013 >> r6 =3D 0x00000128 r7 =3D 0x00000005 >> r8 =3D 0x00000005 r9 =3D 0xd2ebeca0 >> r10 =3D 0x00000128 >> doadump() at doadump >> pc =3D 0xc029d3ec lr =3D 0xc05e9bb0 (abort_align) >> sp =3D 0xd2ebebd4 fp =3D 0xd2ebec00 >> r4 =3D 0xc029d3ec r5 =3D 0xd2ebebd4 >> abort_align() at abort_align >> pc =3D 0xc05e9bb0 lr =3D 0xc05e9740 (abort_handler+0x2e0) >> sp =3D 0xd2ebec08 fp =3D 0xd2ebec98 >> r4 =3D 0x00000013 r5 =3D 0x00000128 >> abort_handler() at abort_handler+0x2e0 >> pc =3D 0xc05e9740 lr =3D 0xc05c9dd4 (exception_exit) >> sp =3D 0xd2ebeca0 fp =3D 0xd2ebed60 >> r4 =3D 0x00000000 r5 =3D 0x00000000 >> r6 =3D 0x00000003 r7 =3D 0x00000016 >> r8 =3D 0x00000000 r9 =3D 0xc2280e00 >> r10 =3D 0x00000021 >> exception_exit() at exception_exit >> pc =3D 0xc05c9dd4 lr =3D 0xc067d61c (ti_adc_intr+0x88) >> sp =3D 0xd2ebed30 fp =3D 0xd2ebed60 >> r0 =3D 0x00000000 r1 =3D 0x00000003 >> r2 =3D 0x00000001 r3 =3D 0x00000000 >> r4 =3D 0x00000000 r5 =3D 0x00000000 >> r6 =3D 0x00000003 r7 =3D 0x00000016 >> r8 =3D 0x00000000 r9 =3D 0xc2280e00 >> r10 =3D 0x00000021 r12 =3D 0xc0ace03c >> evdev_push_event() at evdev_push_event+0x4c >> pc =3D 0xc00888c0 lr =3D 0xc067d61c (ti_adc_intr+0x88) >> sp =3D 0xd2ebed68 fp =3D 0xd2ebedd0 >> r4 =3D 0xd2fce800 r5 =3D 0xc2277d00 >> r6 =3D 0x00000000 r7 =3D 0x00000421 >> r8 =3D 0xc2277d18 r9 =3D 0xc2280e00 >> ti_adc_intr() at ti_adc_intr+0x88 >> pc =3D 0xc067d61c lr =3D 0xc02662fc (ithread_loop+0x1f0) >> sp =3D 0xd2ebedd8 fp =3D 0xd2ebee20 >> r4 =3D 0xd2fce800 r5 =3D 0x00000000 >> r6 =3D 0xd2fce844 r7 =3D 0x00000000 >> r8 =3D 0xc0719541 r9 =3D 0xc2280e00 >> r10 =3D 0x00000000 >> ithread_loop() at ithread_loop+0x1f0 >> pc =3D 0xc02662fc lr =3D 0xc0262ef8 (fork_exit+0xa0) >=20 > That's a strange exception stack, with lots of registers containing > zeroes at exception time that were non-zero in the prior stack frame. > It makes me think something has overwritten the stack with garbage > data. When I look at ti_adc_tsc_read_data() it has a stack-allocated > data array with 16 elements, and a loop that could load more than 16 > elements into that array (ADC_FIFO_COUNT_MSK is 0x7f), that seems like > trouble. >=20 > You said you don't need interrupts, does that mean you're reading the > values via sysctl and aren't using the EVDEV stuff? If so, you might = be > able to quickly work around the panic by building a custom kernel = using > 'nooption EVDEV_SUPPORT'. I forgot to mention, that at the time of the panic, = dev.ti_adc.0.ain.0.enable and dev.ti_adc.0.ain.1.enable were not set to = 1 (enabled) yet, and were not expected to read anything. Yes, I only need the values in defined time intervals and I poll the ADC = readings with the sysctlbyname() function. I compared an (arbitrarily) old version of ti_adc_intr(void *arg) in = ti_adc.c with the current one. The infinging call happens on line 508, = and it is TI_ADC_LOCK(sc);. The striking difference between the old and = the new code is that in the latter one TI_ADC_LOCK(sc); is called = unconditionally, while in the old one the following check happens before = TI_ADC_LOCK(sc); may be get called: ti_adc_intr(void *arg) from 2014: status =3D ADC_READ4(sc, ADC_IRQSTATUS); if (status =3D=3D 0) return; I started to set up a cross building environment on a fast i7 box. My = plan is to place above check into the said function. If this doesn't = help, I will rebuild the kernel with 'nooption EVDEV_SUPPORT'. Thank you = for pointing me into that direction. I even don't know what EVDEV is = good for. Best regards Rolf= From owner-freebsd-arm@freebsd.org Sun Sep 2 16:14:18 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC5ACFF3480 for ; Sun, 2 Sep 2018 16:14:17 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B3537E65D for ; Sun, 2 Sep 2018 16:14:17 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 3a47f8ab-aecb-11e8-a747-09a40681ccbf X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 3a47f8ab-aecb-11e8-a747-09a40681ccbf; Sun, 02 Sep 2018 16:14:12 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w82GEAol024890; Sun, 2 Sep 2018 10:14:11 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1535904850.9486.15.camel@freebsd.org> Subject: Re: Kernel Panic on BBB cause by ti_adc intr From: Ian Lepore To: "Dr. Rolf Jansen" Cc: freebsd-arm@freebsd.org Date: Sun, 02 Sep 2018 10:14:10 -0600 In-Reply-To: <09B4DAE6-4021-4D77-8D74-6E112EE5E9E8@obsigna.com> References: <1535900968.9486.5.camel@freebsd.org> <09B4DAE6-4021-4D77-8D74-6E112EE5E9E8@obsigna.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 16:14:18 -0000 On Sun, 2018-09-02 at 12:40 -0300, Dr. Rolf Jansen wrote: > > > > Am 02.09.2018 um 12:09 schrieb Ian Lepore : > > > > On Sun, 2018-09-02 at 00:15 -0300, Dr. Rolf Jansen wrote: > > > > > > I got signal sources connected to AIN0 and AIN1 of the BBB. The > > > signals are divided, clipped and clamped and are guaranteed to > > > stay > > > in the range of 0 to 1.8 V. Generally, the circuitry does work > > > and > > > the ADC readings match very well the expectations. > > > > > > Only, sometimes, usually when I power on some considerable load > > > (e.g. > > > a hair dryer) connected to a different AC plug, but in the same > > > room, > > > the BBB bails out, giving the stack backtrace shown below. It > > > might > > > well be, that a power-on spike traverses the AC electricity > > > supply, > > > but there is no way that the spike after clipping and clamping > > > would > > > exceed said limits. > > > > > > My understanding of the stack backtrace is, that somehow an > > > interrupt > > > is triggered by said spike, and then it hits a bug in the > > > interrupt > > > handler. It seems that an exclusive sleep mutex is locked when it > > > is > > > not expected to be. This happened on FreeBSD 12.0-ALPHA3 and > > > today > > > also on -ALPHA4. > > > > > > Question: > > > > > >    I don't need interrupt handling in my project, since the > > > signal > > >    changes are slow, and the changes need to be read in defined > > >    time intervals. So, is it possible to deactivate the interrupt > > >    handler of the ti_adc? > > > > > > Presumably then the feature of the exclusive sleep mutex on > > > ti_adc0 > > > would not be challenged and therefore may continue sleeping > > > forever. > > > Of course, I want continue being able of timed reading of the ADC > > > values. > > > > > > Any suggestions would be greatly appreciated, since a BBB which > > > can > > > be DoS'ed by powering on a hair dryer is not as useful as it > > > could > > > be. > > > > > > Best regards > > > > > > Rolf > > > > > > > > > Kernel page fault with the following non-sleepable locks held: > > > exclusive sleep mutex ti_adc0 (ti_adc) r = 0 (0xc2277d08) locked > > > @ > > > /usr/src/sys/arm/ti/ti_adc.c:508 > > > stack backtrace: > > > Fatal kernel mode data abort: 'Translation Fault (L1)' on read > > > trapframe: 0xd2ebeca0 > > > FSR=00000005, FAR=00000128, spsr=20000013 > > > r0 =00000000, r1 =00000003, r2 =00000001, r3 =00000000 > > > r4 =00000000, r5 =00000000, r6 =00000003, r7 =00000016 > > > r8 =00000000, r9 =c2280e00, r10=00000021, r11=d2ebed60 > > > r12=c0ace03c, ssp=d2ebed30, slr=c067d61c, pc =c00888c0 > > > > > > panic: Fatal abort > > > cpuid = 0 > > > time = 1535844155 > > > KDB: stack backtrace: > > > db_trace_self() at db_trace_self > > > pc = 0xc05c7484  lr = 0xc0075d04 (db_trace_self_wrapper+0x30) > > > sp = 0xd2ebea80  fp = 0xd2ebeb98 > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > > > pc = 0xc0075d04  lr = 0xc029d60c (vpanic+0x16c) > > > sp = 0xd2ebeba0  fp = 0xd2ebebc0 > > > r4 = 0x00000100  r5 = 0x00000001 > > > r6 = 0xc071bb22  r7 = 0xc0a8cfd8 > > > vpanic() at vpanic+0x16c > > > pc = 0xc029d60c  lr = 0xc029d3ec (doadump) > > > sp = 0xd2ebebc8  fp = 0xd2ebebcc > > > r4 = 0xd2ebeca0  r5 = 0x00000013 > > > r6 = 0x00000128  r7 = 0x00000005 > > > r8 = 0x00000005  r9 = 0xd2ebeca0 > > > r10 = 0x00000128 > > > doadump() at doadump > > > pc = 0xc029d3ec  lr = 0xc05e9bb0 (abort_align) > > > sp = 0xd2ebebd4  fp = 0xd2ebec00 > > > r4 = 0xc029d3ec  r5 = 0xd2ebebd4 > > > abort_align() at abort_align > > > pc = 0xc05e9bb0  lr = 0xc05e9740 (abort_handler+0x2e0) > > > sp = 0xd2ebec08  fp = 0xd2ebec98 > > > r4 = 0x00000013  r5 = 0x00000128 > > > abort_handler() at abort_handler+0x2e0 > > > pc = 0xc05e9740  lr = 0xc05c9dd4 (exception_exit) > > > sp = 0xd2ebeca0  fp = 0xd2ebed60 > > > r4 = 0x00000000  r5 = 0x00000000 > > > r6 = 0x00000003  r7 = 0x00000016 > > > r8 = 0x00000000  r9 = 0xc2280e00 > > > r10 = 0x00000021 > > > exception_exit() at exception_exit > > > pc = 0xc05c9dd4  lr = 0xc067d61c (ti_adc_intr+0x88) > > > sp = 0xd2ebed30  fp = 0xd2ebed60 > > > r0 = 0x00000000  r1 = 0x00000003 > > > r2 = 0x00000001  r3 = 0x00000000 > > > r4 = 0x00000000  r5 = 0x00000000 > > > r6 = 0x00000003  r7 = 0x00000016 > > > r8 = 0x00000000  r9 = 0xc2280e00 > > > r10 = 0x00000021 r12 = 0xc0ace03c > > > evdev_push_event() at evdev_push_event+0x4c > > > pc = 0xc00888c0  lr = 0xc067d61c (ti_adc_intr+0x88) > > > sp = 0xd2ebed68  fp = 0xd2ebedd0 > > > r4 = 0xd2fce800  r5 = 0xc2277d00 > > > r6 = 0x00000000  r7 = 0x00000421 > > > r8 = 0xc2277d18  r9 = 0xc2280e00 > > > ti_adc_intr() at ti_adc_intr+0x88 > > > pc = 0xc067d61c  lr = 0xc02662fc (ithread_loop+0x1f0) > > > sp = 0xd2ebedd8  fp = 0xd2ebee20 > > > r4 = 0xd2fce800  r5 = 0x00000000 > > > r6 = 0xd2fce844  r7 = 0x00000000 > > > r8 = 0xc0719541  r9 = 0xc2280e00 > > > r10 = 0x00000000 > > > ithread_loop() at ithread_loop+0x1f0 > > > pc = 0xc02662fc  lr = 0xc0262ef8 (fork_exit+0xa0) > > That's a strange exception stack, with lots of registers containing > > zeroes at exception time that were non-zero in the prior stack > > frame. > > It makes me think something has overwritten the stack with garbage > > data. When I look at ti_adc_tsc_read_data() it has a stack- > > allocated > > data array with 16 elements, and a loop that could load more than > > 16 > > elements into that array (ADC_FIFO_COUNT_MSK is 0x7f), that seems > > like > > trouble. > > > > You said you don't need interrupts, does that mean you're reading > > the > > values via sysctl and aren't using the EVDEV stuff? If so, you > > might be > > able to quickly work around the panic by building a custom kernel > > using > > 'nooption EVDEV_SUPPORT'. > I forgot to mention, that at the time of the panic, > dev.ti_adc.0.ain.0.enable and dev.ti_adc.0.ain.1.enable were not set > to 1 (enabled) yet, and were not expected to read anything. > > Yes, I only need the values in defined time intervals and I poll the > ADC readings with the sysctlbyname() function. > > I compared an (arbitrarily) old version of ti_adc_intr(void *arg) in > ti_adc.c with the current one. The infinging call happens on line > 508, and it is TI_ADC_LOCK(sc);. The striking difference between the > old and the new code is that in the latter one TI_ADC_LOCK(sc); is > called unconditionally, while in the old one the following check > happens before TI_ADC_LOCK(sc); may be get called: > > ti_adc_intr(void *arg) from 2014: > > status = ADC_READ4(sc, ADC_IRQSTATUS); > if (status == 0) > return; > > I started to set up a cross building environment on a fast i7 box. My > plan is to place above check into the said function. If this doesn't > help, I will rebuild the kernel with 'nooption EVDEV_SUPPORT'. Thank > you for pointing me into that direction. I even don't know what EVDEV > is good for. > > Best regards > > Rolf The problem isn't the fact that the interrupt routine takes a lock, the problem is that while holding the lock, a page fault occurs; the page fault is the actual problem. The reason for the page fault appears to be that something is dereferencing a NULL pointer. I'm inferring that from the Fault Address Register (FAR) in the exception being 0x128... a number that small is typically generated by accessing a field of a struct through a NULL pointer. So the question is, which pointer is NULL and why? Now that I look at the code a bit closer, I'm not sure turning off EVDEV_SUPPORT will help; it will likely just change the symptom to some other kind of panic or fault in another location. I think the EVDEV stuff has something to do with using the adc as a touchscreen input device controller. A better attempt to work around the problem may be to change the size of the data[] array on line 430 from 16 to 128. If that helps it'll be a powerful clue and we can look for a permanent fix. -- Ian From owner-freebsd-arm@freebsd.org Sun Sep 2 16:33:38 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C700BFF3BE7 for ; Sun, 2 Sep 2018 16:33:37 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 661A57F6A0 for ; Sun, 2 Sep 2018 16:33:37 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: by mailman.ysv.freebsd.org (Postfix) id 23A05FF3BE6; Sun, 2 Sep 2018 16:33:37 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0190AFF3BE4 for ; Sun, 2 Sep 2018 16:33:37 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 974A17F69F for ; Sun, 2 Sep 2018 16:33:36 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-42bc70d5.06-431-73746f70.bbcust.telenor.se ([213.112.188.66] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fwVJe-000G3Y-PL; Sun, 02 Sep 2018 18:33:34 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=tKwMDma0mr91KTyw4y4SKYyA0uv4lKKSaH1voLkk3V8=; b=CV0EhAZ9mE9UcVIqtFA1SCevaN wjAPENnSihtiHDqUW7zbiBL8OuwDxxZ1T2U1I7ll0mfMjbMX1Uqdfi5mvbXTOhMSTV8FGM6HK9bF6 fqch5+WK2s7vad6+MsyPIO1GmEqidLEFgkc6wxePHvNFvu/Q5kavY5N7Q8N1XnjjH73aKB+i/STeP BZutyBPTBDfDKAAQb+Z+hzndDgc19pzhKtDZ5Iy8FDnebZRkB/sFIXXd/TGIZqb4PC1fcPg+gXaBu MtKYDswOcBctQMBeWIrCAE+FlaLqCK+yVT7sSHijH7vGiBJsMYzWQke/O1iJ5gFIToxcQaCRrzg8p NaYP6rNQ==; Received: from [192.168.67.33] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fwVJe-0002jz-B6; Sun, 02 Sep 2018 18:33:34 +0200 Subject: Re: allwinner/nanopi neo boot issues To: Emmanuel Vadot Cc: Daniel Braniss , "freebsd-arm@freebsd.org" References: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> <0fdbd315-f37d-e3d3-9309-612f53c4d379@alvermark.net> <8459A9BA-183A-461B-9050-3631C51218F9@cs.huji.ac.il> <474af48e-ba82-62ce-34a3-70dfc4382723@alvermark.net> <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> <03d4cb0a-c218-a186-936d-765261da2775@alvermark.net> <20180902172444.c4911c8c65a99a7d5e9fe8fa@bidouilliste.com> From: Jakob Alvermark Message-ID: <4410f41b-79f5-f397-b0b1-84bceae82bd0@alvermark.net> Date: Sun, 2 Sep 2018 18:33:34 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180902172444.c4911c8c65a99a7d5e9fe8fa@bidouilliste.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 16:33:38 -0000 On 9/2/18 5:24 PM, Emmanuel Vadot wrote: > On Sun, 2 Sep 2018 17:14:10 +0200 > Jakob Alvermark wrote: > >> On 9/1/18 10:46 PM, Emmanuel Vadot wrote: >>> On Sat, 1 Sep 2018 15:50:25 +0200 >>> Jakob Alvermark wrote: >>> >>>> On 8/29/18 2:22 PM, Daniel Braniss wrote: >>>>>> On 29 Aug 2018, at 15:17, Jakob Alvermark >>>>> > wrote: >>>>>> >>>>>> >>>>>> On 8/24/18 10:02 AM, Daniel Braniss wrote: >>>>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss >>>>>>> > wrote: >>>>>>>> >>>>>>>> hi, >>>>>>>> with the latest current r338243 no longer boots via ubldr, efi does >>>>>>>> but with overlays I have to manually enter the root partition. >>>>>>>> >>>>>>>> this is where it hangs via ubldr: >>>>>>>> >>>>>>>> Autoboot in 8 seconds, hit [Enter] to boot or any other key to stop >>>>>>>> >>>>>>>> Loading kernel... >>>>>>>> /boot/kernel/kernel text=0x8a0950 data=0xae160+0x184520 >>>>>>>> syms=[0x4+0xa6d70+0x4+0x109f17] >>>>>>>> Loading configured modules... >>>>>>>> /boot/entropy size=0x1000 >>>>>>>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=0x601b >>>>>>>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. >>>>>>>> Kernel entry at 0x42400180... >>>>>>>> Kernel args: (null) >>>>>>>> >>>>>>>> older - r337232 - boots fine, >>>>>>>> >>>>>>>> any ideas where to look? >>>>>>> should have done an update before writing! >>>>>>> >>>>>>> with the latest (and greatest) all is back to normal! >>>>>>> so now on to test orange pi one(h3), nanopi neo 2 (h5) and nanopi >>>>>>> neo a64 >>>>>>> >>>>>>> thanks, >>>>>>> danny >>>>>> Hi, >>>>>> >>>>>> >>>>>> I am trying to get an Orange Pi R1 going, I get the same. >>>>>> >>>>>> Loading kernel... >>>>>> /boot/kernel/kernel text=0x89ee40 data=0xae620+0x1f5ba0 >>>>>> syms=[0x4+0xa6d20+0x4+0x109e51] >>>>>> Loading configured modules... >>>>>> Could not load one or more modules! >>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333 >>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >>>>>> Kernel entry at 0x42400180... >>>>>> Kernel args: (null) >>>>>> >>>>>> This is at r338369. >>>>>> >>>>>> >>>>> try booting via efi; >>>>> make sure to copy /boot/loader.efi to /boot/msdos/EFI/BOOT/bootaa64.efi >>>>> remove /boot/msdos/boot.scr >>>>> good luck, >>>>> danny >>>> I tried the ALPHA4 snapshot, this happens: >>>> >>>> Hit any key to stop autoboot:  0 >>>> switch to partitions #0, OK >>>> mmc0 is current device >>>> Scanning mmc 0:1... >>>> 25395 bytes read in 4 ms (6.1 MiB/s) >>>> Found EFI removable media binary efi/boot/bootarm.efi >>>> Scanning disks on usb... >>>> Disk usb0 not ready >>>> Disk usb1 not ready >>>> Disk usb2 not ready >>>> Disk usb3 not ready >>>> Scanning disks on mmc... >>>> MMC Device 1 not found >>>> MMC Device 2 not found >>>> MMC Device 3 not found >>>> Found 3 disks >>>> 508704 bytes read in 26 ms (18.7 MiB/s) >>>> ## Starting EFI application at 42000000 ... >>>> Consoles: EFI console >>>> failed to allocate staging area: 14 >>>> failed to allocate staging area >>>> ## Application terminated, r = 5 >>>> EFI LOAD FAILED: continuing... >>>> >>>> >>>> Tried manually loading ubldr.bin: >>>> >>>> => fatload mmc 0 0x42000000 ubldr.bin >>>> 306972 bytes read in 15 ms (19.5 MiB/s) >>>> => go 0x42000000 >>>> Loading kernel... >>>> /boot/kernel/kernel text=0x85d7f0 data=0xaf620+0x24e1e0 >>>> syms=[0x4+0xa87d0+0x4+0x10c603] >>>> Loading configured modules... >>>> /boot/kernel/umodem.ko text=0x1bf4 text=0x1320 data=0x1080+0xf88 >>>> syms=[0x4+0x1070+0x4+0xbcd] >>>> loading required module 'ucom' >>>> /boot/kernel/ucom.ko text=0x1f8c text=0x2e90 data=0x1080+0x17bc >>>> syms=[0x4+0x14f0+0x4+0xc5d] >>>> Could not load one or more modules! >>>> >>>> Hit [Enter] to boot immediately, or any other key for command prompt. >>>> Booting [/boot/kernel/kernel]... >>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333 >>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >>>> Kernel entry at 0x42400180... >>>> Kernel args: (null) >>>> >>>> And then it reboots... >>> I've just re-introduce the cache patches for u-boot as it appears that >>> some boards needs them (I've probably tested the wrong unpatched u-boot >>> when I removed them ...) so booting with ubldr.bin should work now. >>> For the EFI issue I don't really know what is happening. >> >> Thanks! With the updated U-boot it now boots with ubldr.bin. >> >> How can I make it do this automatically? > If you copy the boot.scr file from the port/package to the root of the > fat partition this will load ubldr.bin directly. Thanks again! It works! > I'm more interested to debug the efi problem, I'll try on a H2 board. If there is anything I can do to help let me know. I tried with boot1.efi as /efi/boot/bootarm.efi: ## Starting EFI application at 42000000 ... >> FreeBSD EFI boot block    Loader path: /boot/loader.efi    Initializing modules: UFS    Load Path: /\efi\boot\bootarm.efi    Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x800,0x2000)    Probing 3 block devices.....* done     UFS found 1 partition Consoles: EFI console failed to allocate staging area: 14 failed to allocate staging area Failed to start image provided by UFS (5) panic: No bootable partitions found! ## Application terminated, r = 1 EFI LOAD FAILED: continuing... >> Also, the network interface does not attach: >> >> awg0: mem 0x1c30000-0x1c3ffff irq 22 on >> simplebus0 >> awg0: soft reset timed out >> device_attach: awg0 attach returned 60 > Yes there is a problem on some boards when the cable isn't connected, > someone (tm) will need to debug that one day. Alright, with a cable connected during boot it works. From owner-freebsd-arm@freebsd.org Sun Sep 2 16:39:03 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32272FF3CB2 for ; Sun, 2 Sep 2018 16:39:03 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A0C2D7F76B for ; Sun, 2 Sep 2018 16:39:02 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 729558b2-aecc-11e8-ac8d-0b43254c4a2d X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 729558b2-aecc-11e8-ac8d-0b43254c4a2d; Sun, 02 Sep 2018 16:22:56 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w82GMt1w024901; Sun, 2 Sep 2018 10:22:55 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1535905375.9486.18.camel@freebsd.org> Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024") From: Ian Lepore To: bob prohaska , Mark Millard Cc: freebsd-arm@freebsd.org Date: Sun, 02 Sep 2018 10:22:55 -0600 In-Reply-To: <20180902152717.GB44384@www.zefox.net> References: <20180814014226.GA50013@www.zefox.net> <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <20180902083217.GA44384@www.zefox.net> <6B8E28DC-075D-4829-9BEA-F36DDB1E2A25@yahoo.com> <20180902152717.GB44384@www.zefox.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 16:39:03 -0000 On Sun, 2018-09-02 at 08:27 -0700, bob prohaska wrote: > On Sun, Sep 02, 2018 at 06:57:15AM -0700, Mark Millard wrote: > > Was this with or without (presuming a ufs file system): > >  > > tunefs: trim: (-t)                                         enabled > >  > > ? If enabled, with or without: > >  > > sysctl vfs.ffs.dotrimcons=1 > >  > > In other words: was "consolidation of TRIM / BIO_DELETE > > commands to the UFS/FFS filesystem" enabled? Disabled? > >  > > No, it was not. By all accounts TRIM enabling won't affect USB2.0 devices, > and it's fairly clear the bottleneck is in USB, not microSD. Trim is enabled > for mmcsd0s2a, but sysctl vfs.ffs.dotrimcons=1 hasn't been invoked. I'll turn > it on later, to check for bad side effects, but there's no obvious reason to > think it'll help. Trim consolidation at the ufs layer might not have as much effect on mmcsd as it does on other devices. The mmcsd driver has always consolidated adjacent trim requests itself even when they arrive in the IO queue as a large number of small BIO_DELETE commands. It assembles blocks of adjacent deletes until they reach the size of a full erase block, then issue one erase command (I've never been convinced that doing so is necessary, to me the sd spec implies you can delete individual sectors). -- Ian From owner-freebsd-arm@freebsd.org Sun Sep 2 17:57:01 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C411DFF5420 for ; Sun, 2 Sep 2018 17:57:01 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6945D818C3 for ; Sun, 2 Sep 2018 17:57:01 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1fwWcH-0003eN-Pt; Sun, 02 Sep 2018 19:56:54 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Mark Millard" , "bob prohaska" Cc: freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024") References: <20180814014226.GA50013@www.zefox.net> <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <20180902083217.GA44384@www.zefox.net> <6B8E28DC-075D-4829-9BEA-F36DDB1E2A25@yahoo.com> <20180902152717.GB44384@www.zefox.net> Date: Sun, 02 Sep 2018 19:56:54 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <20180902152717.GB44384@www.zefox.net> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 388a8ff653e0601f0215f26536afca72 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 17:57:02 -0000 On Sun, 02 Sep 2018 17:27:17 +0200, bob prohaska wrote: > On Sun, Sep 02, 2018 at 06:57:15AM -0700, Mark Millard wrote: >> Was this with or without (presuming a ufs file system): >> >> tunefs: trim: (-t) enabled >> >> ? If enabled, with or without: >> >> sysctl vfs.ffs.dotrimcons=1 >> >> In other words: was "consolidation of TRIM / BIO_DELETE >> commands to the UFS/FFS filesystem" enabled? Disabled? >> > > No, it was not. By all accounts TRIM enabling won't affect USB2.0 > devices, > and it's fairly clear the bottleneck is in USB, not microSD. Trim is > enabled > for mmcsd0s2a, but sysctl vfs.ffs.dotrimcons=1 hasn't been invoked. I'll > turn Sysctl vfs.ffs.dotrimcons is about FFS/UFS. Not about swap. So unless there is UFS on the same device as swap, the sysctl will not have any effect. Regards, Ronald. > it on later, to check for bad side effects, but there's no obvious > reason to > think it'll help. > > At the moment the diskscript is reporting: > > dT: 10.005s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 9 5.2 0 0 > 0.0 0.2 mmcsd0 > 10 0 0 0 0.0 0 2 13790 0 0 > 0.0 89.9 da0 > 0 0 0 0 0.0 0 2 3.9 0 0 > 0.0 0.1 mmcsd0s2b > 0 0 0 0 0.0 0 9 5.2 0 0 > 0.0 0.2 mmcsd0s2 > 9 0 0 0 0.0 0 2 13790 0 0 > 0.0 89.9 da0b > Sun Sep 2 08:17:14 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 494352 554224 47% > /dev/mmcsd0s2b 1048576 478860 569716 46% > Total 2097152 973212 1123940 46% > Sep 2 08:14:38 www kernel: swap_pager: indefinite wait buffer: bufobj: > 0, blkno: 1649558, size: 4096 > Sep 2 08:14:38 www kernel: swap_pager: indefinite wait buffer: bufobj: > 0, blkno: 1654590, size: 16384 > > Top is reporting ~10-50% idle time, not surprising given delays writing > to da0b. > I was hoping the pager might favor microSD given the much faster I/O > times, > but evidently not. Seems to be a strict round-robin division of labor. > > Thanks for reading! > > bob prohaska > _______________________________________________ > 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 Sun Sep 2 18:56:54 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD370FF6FF6 for ; Sun, 2 Sep 2018 18:56:54 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 13656836B9 for ; Sun, 2 Sep 2018 18:56:53 +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 w82IvBbq046479 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Sep 2018 11:57:12 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w82IvBKv046478; Sun, 2 Sep 2018 11:57:11 -0700 (PDT) (envelope-from fbsd) Date: Sun, 2 Sep 2018 11:57:11 -0700 From: bob prohaska To: Ronald Klop Cc: Mark Millard , freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024") Message-ID: <20180902185711.GC44384@www.zefox.net> References: <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <20180902083217.GA44384@www.zefox.net> <6B8E28DC-075D-4829-9BEA-F36DDB1E2A25@yahoo.com> <20180902152717.GB44384@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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 18:56:54 -0000 On Sun, Sep 02, 2018 at 07:56:54PM +0200, Ronald Klop wrote: > On Sun, 02 Sep 2018 17:27:17 +0200, bob prohaska > wrote: > > > On Sun, Sep 02, 2018 at 06:57:15AM -0700, Mark Millard wrote: > >> Was this with or without (presuming a ufs file system): > >> > >> tunefs: trim: (-t) enabled > >> > >> ? If enabled, with or without: > >> > >> sysctl vfs.ffs.dotrimcons=1 > >> > >> In other words: was "consolidation of TRIM / BIO_DELETE > >> commands to the UFS/FFS filesystem" enabled? Disabled? > >> > > > > No, it was not. By all accounts TRIM enabling won't affect USB2.0 > > devices, > > and it's fairly clear the bottleneck is in USB, not microSD. Trim is > > enabled > > for mmcsd0s2a, but sysctl vfs.ffs.dotrimcons=1 hasn't been invoked. I'll > > turn > > Sysctl vfs.ffs.dotrimcons is about FFS/UFS. Not about swap. > So unless there is UFS on the same device as swap, the sysctl will not > have any effect. > In the present setup there is ufs on both mmcsd0 and da0: / is still on mmcsd0; /var/, /tmp/ and /usr/ are all on da0 and there are three swap partitions on each device, usually enabled pairwise. Usual practice is to run make cleandir twice, run rm -rf /usr/obj/usr/src once and then run -j4 buildworld. Seemingly all of the delete activity should finish before any compiler activity starts. Is that how the system really behaves? If it "saves up" deletes until something wants to write to the no-longer-needed storage space that might explain some of the congestion issues. In a few cases I've happpened upon the top window when things were going very slowly. Checking gstat's output showed initial congestion of both da0g (/usr) and swap (e.g., da0b), followed by prolonged congestion of da0g. In the same interval da0b ceased to be an obstruction, but idle times often remained about 50% in top. One should take my tale with a grain of salt, it's only casual observation, but it is suggestive. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Mon Sep 3 06:21:48 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55ADEFDF53B for ; Mon, 3 Sep 2018 06:21:48 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C966576EAB; Mon, 3 Sep 2018 06:21:47 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id j25-v6so8008811wmc.1; Sun, 02 Sep 2018 23:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=rFd7ZQfcMf14IeLFVKbMTpb1Ak1BnpSu4tROgXnkPcA=; b=uAl3rT9jqs7etvwSdiLsA/iFgbMDFHnXdwntKEtwf01R9arUK0LgZ2UOJmvoq99IeJ tSJEvSd9BOS2D47cvWYHCSUqNS+EU/mp4q3qElatY8L180Qx4kQpE28LZPObGrVJ1wlU 2pVvGNMfwtZtBwvHrj1U3XzkZ1R/8y0hfeig5pCzsxNiQFB8I/a+uHtm+91yTDlAYEzg sbpQMlWMgd1M2MxJC+JjmTSszshuSe+2X3RU+bkZLdrkIzPWYnXpM1UyPJu6tkEGsJ5I 3eYUFoTxpINseZAWv/QHDaRlL2991f0ZW01Dnjylmf/DsQM0lG+YhanclbOORbFhyGcE +Igg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=rFd7ZQfcMf14IeLFVKbMTpb1Ak1BnpSu4tROgXnkPcA=; b=rwWIrhsyPD8u+NlkBxgya7Z9BfKJAzqWb/kw9wysQHaoCO9hjaP//kvkVsWSre1HUr x0FEqFMVp/O3i0ilRkp4aK6RTZAJuBomKglBpXojWnsdGDhjEdXcQZKBcGgEAQpahOcX reBN2S8wofYVZnpeG7xAMFAMjnh7u3tvKh4Q0h68rh8WxkPuOtzOZ2boqwpwGr+W4t/b dYWbxa+6ox4S0jNi57sE26qGaDxpXrh0zqCB+eYk47WQvT2yHfaCdxDL+lHMLITeLDpr LtpE7DI51G8bJuvxGVbkfKS02yaQMxnQa+DPkbFVcq37QKBU0K2wLTYsanMBHPfHKVSc m75w== X-Gm-Message-State: APzg51DYyK1ofwoHyRqz6fr956phzY9kEjegqIooan88CqN7bYhuf03W rae15P8enbCcUsfzkPm3Zas= X-Google-Smtp-Source: ANB0Vdb64B+yO1uU5z1DLkg++SIPEZLf1XKQyd6u20B7fa5tiMrQlvxH4pzMmPzXZWSD3nDEKPl15w== X-Received: by 2002:a1c:a187:: with SMTP id k129-v6mr4009490wme.111.1535955706747; Sun, 02 Sep 2018 23:21:46 -0700 (PDT) Received: from [172.16.0.150] (net-188-219-105-237.cust.vodafonedsl.it. [188.219.105.237]) by smtp.gmail.com with ESMTPSA id e141-v6sm13447572wmd.32.2018.09.02.23.21.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Sep 2018 23:21:45 -0700 (PDT) Subject: Re: utility for pin in BBB: PX.Y --> pin_mode, pin_name To: Ian Lepore , Russell Haley Cc: freebsd-arm , "nmi >> Nicola Mingotti" References: <4661fc41-935a-56d5-2cc2-125085daf30a@gmail.com> <1535568374.33841.47.camel@freebsd.org> <1535576856.33841.58.camel@freebsd.org> <1535643488.33841.74.camel@freebsd.org> From: Nicola Mingotti Message-ID: Date: Mon, 3 Sep 2018 08:21:44 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1535643488.33841.74.camel@freebsd.org> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 06:21:48 -0000 On 08/30/18 17:38, Ian Lepore wrote: > On Wed, 2018-08-29 at 23:40 +0200, Nicola Mingotti wrote: >> On 08/29/18 23:07, Ian Lepore wrote: >>> On Wed, 2018-08-29 at 22:26 +0200, Nicola Mingotti wrote: >>>> On 08/29/18 20:46, Ian Lepore wrote: >>>>> On Wed, 2018-08-29 at 20:01 +0200, Nicola Mingotti wrote: >>>>>> Thank you for suggestion Russel, >>>>>> >>>>>> but unfortunately, at best of my knowldege, >>>>>> $> man 3 gpio_open >>>>>> and its shell command brother >>>>>> $> man 8 gpioctl >>>>>> >>>>>> are not appropriate, they are useful only if a pin >>>>>> has been configured as GPIO pin. >>>>>> >>>>>> The program i look for would be useful instead to esablish >>>>>> which physical pin has been configured as GPIO pin or >>>>>> PWM, PRU, I2C etc. >>>>>> >>>>>> I asked also in the Forum, but the only one aswering >>>>>> (@Phishry) has given me your same suggestion. >>>>>> >>>>>> If nobody knows of such a program i will start the >>>>>> implementation, >>>>>> maybe >>>>>> tomorrow. >>>>>> >>>>>> bye >>>>>> Nicola >>>>>> >>>>> Please bottom-post when replying to freebsd mailing lists. >>>> ok ! >>>>> There is no interface defined for getting an fdt_pinctrl driver >>>>> to >>>>> return info about the current configuration. Even if such an >>>>> interface >>>>> existed, there would also need to be a new driver providing a >>>>> cdev >>>>> so >>>>> that userland can access the information. >>>> ok, no interface. >>>>> There is also nothing in freebsd equivelent to the linux >>>>> devmem2 >>>>> program. A driver would have to be written to provide access to >>>>> device- >>>>> mapped memory before such a program could be written. You can't >>>>> access >>>>> arm hardware registers via /dev/mem or /dev/kmem. >>>>> >>>>> -- Ian >>>> I just compiled devmem2 and it seems to work. I did silly >>>> modifications. >>>> The code is here: http://euriscom.it/data/dm2.c >>>> (forget the first comment lines, they are poor, I did not intend >>>> to >>>> share this, it is my working copy) >>>> >>>> if i run it: >>>> --------------------------------- >>>> #> ./dm2 0x44e10998 b >>>> /dev/mem opened. >>>> Memory mapped at address 0x20221000. >>>> Value at address 0x44E10998 (0x20221998): 0x5 >>>> --------------------------------- >>>> >>>> Whic corresponds to what i wrote in the DTO. >>>> ----- >>>>              pru_pru_pins: pinmux_pru_pru_pins { >>>>                         pinctrl-single,pins = < >>>>                             // 0x1a4 0x05   /* P9.27 >>>> pr1_pru0_pru_r30_5, >>>> Mode 5 output pull-down   */ >>>>                             0x19c 0x26   /* P9.28 >>>> pr1_pru0_pru_r31_3, >>>> Mode 6 input pull-down    */ >>>>                             0x198 0x05    /* PRU0-2 -- P9.30 -- >>>> pr1_pru0_pru_r30_2 ... se in MODE-5  */ >>>>                             >; >>>>                     }; >>>> ----- >>>> >>>> This is the only test i made but it seems improbable I got the >>>> same >>>> value by chance;) >>>> >>>> It goes without saying that I don't understand all what i wrote, >>>> so, i could be boldly wrong ;) >>>> >>>> If it turns out it works let me know, i can make the port. >>>> >>>> bye >>>> n. >>> You might accidentally get /dev/mem access to work, but it's not by >>> design. The rules of the arm memory model forbid mapping the same >>> physical memory to different virtual addresses using different >>> attributes (normal cacheable memory versus Device memory), and I >>> don't >>> see anything in the arm devmem code that handles memory attributes. >>> >>> -- Ian >> I would like to discuss more this thing but really, i am too ignorant >> on >> this subject. >> >> What i can say is this, I learnt to use devmem2 from D.Molloy book >> "Exploring BeagleBone", >> see pg. 218. The author says this way "bypasses the Linux OS". I >> used >> the thing >> in Linux, it works, as it seems to do in FreeBSD-12-APLHA. >> >> If can tell you also I remember i used it one day in FreeBSD-11.1, >> it >> was working. >> >> I don't have the background to go deeper. >> >> If you can understand why it works and establish that it is realiable >> (even only for reading) let me (us) know ! ;) >> >> bye >> n. >> > I think it should be possible to do a bit of kernel work to change it > from "works by accident" to "does the right thing", except I'm not sure > it'll be possible to automatically detect when Device memory is being > accessed/mapped. It may be necessary to use the mem(4) ioctls to set > the region to MDF_UNCACHEABLE, or even better, define a new MDF_MMIO > for mapping ranges of device registers that arm systems have to treat > as memory type Device. I'll look into it when I have some time. > > -- Ian Hi, After a suggestion from @Phisfry on the forum I guess found a way to bypass the need of devmem2 to write my "pinfunc" utlity. I can read (all?) pin configurations from "ofwdump -a -p", indeed I see blocks like this: ---------------------- #> ofwdump -a -p ----------   Node 0x30f4: pinmux_ehrpwm0_AB_pins             phandle:               00 00 00 ce             pinctrl-single,pins:               00 00 01 54 00 00 00 03 00 00 01 50 00 00 00 03 ---------- So I hopefully wrote my script to parse "ofwdump" and what i got is this, -------------------------- #> pinfunc.rb HEADER   NAME            MODE       FUNCTION ... P.9.10   SYS_RESETn      1          - P.9.11   UART4_RXD       not-found P.9.12   GPIO1_28        not-found P.9.13   UART4_TXD       not-found P.9.14   EHRPWM1A        not-found P.9.15   GPIO1_16        not-found P.9.16   EHRPWM1B        not-found P.9.17   I2C1_SCL        not-found P.9.18   I2C1_SDA        not-found P.9.19   I2C2_SCL        3          I2C2_SCL P.9.20   I2C2_SDA        3          I2C2_SDA P.9.21   UART2_TXD       3          ehrpwm0B P.9.22   UART2_RXD       3          ehrpwm0A P.9.23   GPIO1_17        not-found P.9.24   UART1_TXD       not-found P.9.25   GPIO3_21        0          mcasp0_ahclkx P.9.26   UART1_RXD       not-found P.9.27   GPIO3_19        not-found P.9.28   SPI1_CS0        6          pr1_pru0_pru_r31_3 P.9.29   SPI1_D0         0          mcasp0_fsx P.9.30   SPI1_D1         6          pr1_pru0_pru_r31_2 P.9.31   SPI1_SCLK       0          mcasp0_aclkx P.9.32   VADC ... --------------------------- The only isssue seems to be that GPIO pins do not appear. I could fix the problem parsing the output of "gpioctl -f /dev/gpioX/ -l" But I have a couple of questions : 1] Is there somewhare written the GPIO pins configuration in "ofwdump" ? 2] If it is not written there, what is the reason ? 2.1] Where is the boot GPIO pins configuration written ? 2.2] I looked also in "dtc -I dtb -O dts /boot/dtb/am335x-boneblack.dtb | less" but at the best of my ability to read it I could not find the GPIOs configuration. bye nico -- -------------------------- Dr. Nicola Mingotti R&D - Borghi Srl CTO - BondInsider -------------------------- From owner-freebsd-arm@freebsd.org Mon Sep 3 07:01:48 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DA9BFE045B for ; Mon, 3 Sep 2018 07:01:48 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E95BE77F43 for ; Mon, 3 Sep 2018 07:01:47 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id A4328FE043C; Mon, 3 Sep 2018 07:01:47 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6133FFE0429 for ; Mon, 3 Sep 2018 07:01:47 +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 D417677F3C for ; Mon, 3 Sep 2018 07:01:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1fwirc-00061Y-Rr; Mon, 03 Sep 2018 10:01:32 +0300 From: Daniel Braniss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: allwinner/nanopi neo boot issues Date: Mon, 3 Sep 2018 10:01:32 +0300 In-Reply-To: <4410f41b-79f5-f397-b0b1-84bceae82bd0@alvermark.net> Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" To: Jakob Alvermark References: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> <0fdbd315-f37d-e3d3-9309-612f53c4d379@alvermark.net> <8459A9BA-183A-461B-9050-3631C51218F9@cs.huji.ac.il> <474af48e-ba82-62ce-34a3-70dfc4382723@alvermark.net> <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> <03d4cb0a-c218-a186-936d-765261da2775@alvermark.net> <20180902172444.c4911c8c65a99a7d5e9fe8fa@bidouilliste.com> <4410f41b-79f5-f397-b0b1-84bceae82bd0@alvermark.net> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 07:01:48 -0000 > On 2 Sep 2018, at 19:33, Jakob Alvermark wrote: >=20 > On 9/2/18 5:24 PM, Emmanuel Vadot wrote: >> On Sun, 2 Sep 2018 17:14:10 +0200 >> Jakob Alvermark wrote: >>=20 >>> On 9/1/18 10:46 PM, Emmanuel Vadot wrote: >>>> On Sat, 1 Sep 2018 15:50:25 +0200 >>>> Jakob Alvermark wrote: >>>>=20 >>>>> On 8/29/18 2:22 PM, Daniel Braniss wrote: >>>>>>> On 29 Aug 2018, at 15:17, Jakob Alvermark >>>>>> > wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> On 8/24/18 10:02 AM, Daniel Braniss wrote: >>>>>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>> hi, >>>>>>>>> with the latest current r338243 no longer boots via ubldr, efi = does >>>>>>>>> but with overlays I have to manually enter the root partition. >>>>>>>>>=20 >>>>>>>>> this is where it hangs via ubldr: >>>>>>>>>=20 >>>>>>>>> Autoboot in 8 seconds, hit [Enter] to boot or any other key to = stop >>>>>>>>>=20 >>>>>>>>> Loading kernel... >>>>>>>>> /boot/kernel/kernel text=3D0x8a0950 data=3D0xae160+0x184520 >>>>>>>>> syms=3D[0x4+0xa6d70+0x4+0x109f17] >>>>>>>>> Loading configured modules... >>>>>>>>> /boot/entropy size=3D0x1000 >>>>>>>>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x601b >>>>>>>>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. >>>>>>>>> Kernel entry at 0x42400180... >>>>>>>>> Kernel args: (null) >>>>>>>>>=20 >>>>>>>>> older - r337232 - boots fine, >>>>>>>>>=20 >>>>>>>>> any ideas where to look? >>>>>>>> should have done an update before writing! >>>>>>>>=20 >>>>>>>> with the latest (and greatest) all is back to normal! >>>>>>>> so now on to test orange pi one(h3), nanopi neo 2 (h5) and = nanopi >>>>>>>> neo a64 >>>>>>>>=20 >>>>>>>> thanks, >>>>>>>> danny >>>>>>> Hi, >>>>>>>=20 >>>>>>>=20 >>>>>>> I am trying to get an Orange Pi R1 going, I get the same. >>>>>>>=20 >>>>>>> Loading kernel... >>>>>>> /boot/kernel/kernel text=3D0x89ee40 data=3D0xae620+0x1f5ba0 >>>>>>> syms=3D[0x4+0xa6d20+0x4+0x109e51] >>>>>>> Loading configured modules... >>>>>>> Could not load one or more modules! >>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 >>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >>>>>>> Kernel entry at 0x42400180... >>>>>>> Kernel args: (null) >>>>>>>=20 >>>>>>> This is at r338369. >>>>>>>=20 >>>>>>>=20 >>>>>> try booting via efi; >>>>>> make sure to copy /boot/loader.efi to = /boot/msdos/EFI/BOOT/bootaa64.efi >>>>>> remove /boot/msdos/boot.scr >>>>>> good luck, >>>>>> danny >>>>> I tried the ALPHA4 snapshot, this happens: >>>>>=20 >>>>> Hit any key to stop autoboot: 0 >>>>> switch to partitions #0, OK >>>>> mmc0 is current device >>>>> Scanning mmc 0:1... >>>>> 25395 bytes read in 4 ms (6.1 MiB/s) >>>>> Found EFI removable media binary efi/boot/bootarm.efi >>>>> Scanning disks on usb... >>>>> Disk usb0 not ready >>>>> Disk usb1 not ready >>>>> Disk usb2 not ready >>>>> Disk usb3 not ready >>>>> Scanning disks on mmc... >>>>> MMC Device 1 not found >>>>> MMC Device 2 not found >>>>> MMC Device 3 not found >>>>> Found 3 disks >>>>> 508704 bytes read in 26 ms (18.7 MiB/s) >>>>> ## Starting EFI application at 42000000 ... >>>>> Consoles: EFI console >>>>> failed to allocate staging area: 14 >>>>> failed to allocate staging area >>>>> ## Application terminated, r =3D 5 >>>>> EFI LOAD FAILED: continuing... >>>>>=20 >>>>>=20 >>>>> Tried manually loading ubldr.bin: >>>>>=20 >>>>> =3D> fatload mmc 0 0x42000000 ubldr.bin >>>>> 306972 bytes read in 15 ms (19.5 MiB/s) >>>>> =3D> go 0x42000000 >>>>> Loading kernel... >>>>> /boot/kernel/kernel text=3D0x85d7f0 data=3D0xaf620+0x24e1e0 >>>>> syms=3D[0x4+0xa87d0+0x4+0x10c603] >>>>> Loading configured modules... >>>>> /boot/kernel/umodem.ko text=3D0x1bf4 text=3D0x1320 = data=3D0x1080+0xf88 >>>>> syms=3D[0x4+0x1070+0x4+0xbcd] >>>>> loading required module 'ucom' >>>>> /boot/kernel/ucom.ko text=3D0x1f8c text=3D0x2e90 = data=3D0x1080+0x17bc >>>>> syms=3D[0x4+0x14f0+0x4+0xc5d] >>>>> Could not load one or more modules! >>>>>=20 >>>>> Hit [Enter] to boot immediately, or any other key for command = prompt. >>>>> Booting [/boot/kernel/kernel]... >>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 >>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >>>>> Kernel entry at 0x42400180... >>>>> Kernel args: (null) >>>>>=20 >>>>> And then it reboots... >>>> I've just re-introduce the cache patches for u-boot as it appears = that >>>> some boards needs them (I've probably tested the wrong unpatched = u-boot >>>> when I removed them ...) so booting with ubldr.bin should work now. >>>> For the EFI issue I don't really know what is happening. >>>=20 >>> Thanks! With the updated U-boot it now boots with ubldr.bin. >>>=20 >>> How can I make it do this automatically? >> If you copy the boot.scr file from the port/package to the root of = the >> fat partition this will load ubldr.bin directly. >=20 > Thanks again! It works! >=20 >=20 >> I'm more interested to debug the efi problem, I'll try on a H2 = board. >=20 > If there is anything I can do to help let me know. >=20 > I tried with boot1.efi as /efi/boot/bootarm.efi: >=20 > ## Starting EFI application at 42000000 ... > >> FreeBSD EFI boot block > Loader path: /boot/loader.efi >=20 > Initializing modules: UFS > Load Path: /\efi\boot\bootarm.efi > Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x80= 0,0x2000) > Probing 3 block devices.....* done > UFS found 1 partition > Consoles: EFI console > failed to allocate staging area: 14 > failed to allocate staging area > Failed to start image provided by UFS (5) > panic: No bootable partitions found! > ## Application terminated, r =3D 1 > EFI LOAD FAILED: continuing=E2=80=A6 shot in the dark: I found out that if the root partition is not freebsd-ufs the = efi boot failed. do a gpart show, mine looks like this: neo-001> gpart show =3D> 63 15523777 mmcsd0 MBR (7.4G) 63 1985 - free - (993K) 2048 102400 1 fat32lba [active] (50M) 104448 6187008 2 freebsd (3.0G) 6291456 9232384 - free - (4.4G) =3D> 0 6187008 mmcsd0s2 BSD (3.0G) 0 6187008 1 freebsd-ufs (3.0G) danny From owner-freebsd-arm@freebsd.org Mon Sep 3 08:05:50 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A994CFE1DAA for ; Mon, 3 Sep 2018 08:05:49 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5347A855 for ; Mon, 3 Sep 2018 08:05:49 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: by mailman.ysv.freebsd.org (Postfix) id B7FE8FE1DA6; Mon, 3 Sep 2018 08:05:48 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BC69FE1DA5 for ; Mon, 3 Sep 2018 08:05:48 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 D81CD7A853 for ; Mon, 3 Sep 2018 08:05:47 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-42bc70d5.06-431-73746f70.bbcust.telenor.se ([213.112.188.66] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fwjrl-000Gqk-P1; Mon, 03 Sep 2018 10:05:45 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID :From:References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=FjHTdfGOMayAo7Sz1V0WMtRNjVdfFKE8K1TzmI+BPe4=; b=RqceokDNOAA8z1lrTQJSH6xwB/ MRyjNQ4D/b/9A9Eg8KLfysglsY9dyZ6EshIx58DYnNbE/ZE+h4jNNAsX/r0t4FobwZpHnWilwLuGv ewanegzfslQGoOMx1T/hjSAqOpmITa9KnvGp5Y9XHZY2Mk0IxdWVBcEnBmnPYTjQmJmW0Nm9gf1v1 F+BbM9S1M7gqsXaF+Pk4sB52QP1odc1Eb6i6OPe2+n0EyeFf4UP0wcKOFnEIt5qF2ZfpJKR3CUH3k +IX6Xd+Fo/rWZ+OdG7Q7WROt6kymGcf9S8OJf9w6hoZjWO2IjBAV8kg+srymv08c8gmsNXmomtg3Q fY+9k13A==; Received: from [192.168.67.33] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fwjrl-0009gH-Am; Mon, 03 Sep 2018 10:05:45 +0200 Subject: Re: allwinner/nanopi neo boot issues To: Daniel Braniss Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" References: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> <0fdbd315-f37d-e3d3-9309-612f53c4d379@alvermark.net> <8459A9BA-183A-461B-9050-3631C51218F9@cs.huji.ac.il> <474af48e-ba82-62ce-34a3-70dfc4382723@alvermark.net> <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> <03d4cb0a-c218-a186-936d-765261da2775@alvermark.net> <20180902172444.c4911c8c65a99a7d5e9fe8fa@bidouilliste.com> <4410f41b-79f5-f397-b0b1-84bceae82bd0@alvermark.net> From: Jakob Alvermark Message-ID: Date: Mon, 3 Sep 2018 10:05:44 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 08:05:50 -0000 On 9/3/18 9:01 AM, Daniel Braniss wrote: > > >> On 2 Sep 2018, at 19:33, Jakob Alvermark > > wrote: >> >> On 9/2/18 5:24 PM, Emmanuel Vadot wrote: >>> On Sun, 2 Sep 2018 17:14:10 +0200 >>> Jakob Alvermark > >>> wrote: >>> >>>> On 9/1/18 10:46 PM, Emmanuel Vadot wrote: >>>>> On Sat, 1 Sep 2018 15:50:25 +0200 >>>>> Jakob Alvermark > >>>>> wrote: >>>>> >>>>>> On 8/29/18 2:22 PM, Daniel Braniss wrote: >>>>>>>> On 29 Aug 2018, at 15:17, Jakob Alvermark >>>>>>> >>>>>>>> > wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 8/24/18 10:02 AM, Daniel Braniss wrote: >>>>>>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss >>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> hi, >>>>>>>>>> with the latest current r338243 no longer boots via ubldr, >>>>>>>>>> efi does >>>>>>>>>> but with overlays I have to manually enter the root partition. >>>>>>>>>> >>>>>>>>>> this is where it hangs via ubldr: >>>>>>>>>> >>>>>>>>>> Autoboot in 8 seconds, hit [Enter] to boot or any other key >>>>>>>>>> to stop >>>>>>>>>> >>>>>>>>>> Loading kernel... >>>>>>>>>> /boot/kernel/kernel text=0x8a0950 data=0xae160+0x184520 >>>>>>>>>> syms=[0x4+0xa6d70+0x4+0x109f17] >>>>>>>>>> Loading configured modules... >>>>>>>>>> /boot/entropy size=0x1000 >>>>>>>>>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=0x601b >>>>>>>>>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. >>>>>>>>>> Kernel entry at 0x42400180... >>>>>>>>>> Kernel args: (null) >>>>>>>>>> >>>>>>>>>> older - r337232 - boots fine, >>>>>>>>>> >>>>>>>>>> any ideas where to look? >>>>>>>>> should have done an update before writing! >>>>>>>>> >>>>>>>>> with the latest (and greatest) all is back to normal! >>>>>>>>> so now on to test orange pi one(h3), nanopi neo 2 (h5) and nanopi >>>>>>>>> neo a64 >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> danny >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> I am trying to get an Orange Pi R1 going, I get the same. >>>>>>>> >>>>>>>> Loading kernel... >>>>>>>> /boot/kernel/kernel text=0x89ee40 data=0xae620+0x1f5ba0 >>>>>>>> syms=[0x4+0xa6d20+0x4+0x109e51] >>>>>>>> Loading configured modules... >>>>>>>> Could not load one or more modules! >>>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333 >>>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >>>>>>>> Kernel entry at 0x42400180... >>>>>>>> Kernel args: (null) >>>>>>>> >>>>>>>> This is at r338369. >>>>>>>> >>>>>>>> >>>>>>> try booting via efi; >>>>>>> make sure to copy /boot/loader.efi to >>>>>>> /boot/msdos/EFI/BOOT/bootaa64.efi >>>>>>> remove /boot/msdos/boot.scr >>>>>>> good luck, >>>>>>> danny >>>>>> I tried the ALPHA4 snapshot, this happens: >>>>>> >>>>>> Hit any key to stop autoboot:  0 >>>>>> switch to partitions #0, OK >>>>>> mmc0 is current device >>>>>> Scanning mmc 0:1... >>>>>> 25395 bytes read in 4 ms (6.1 MiB/s) >>>>>> Found EFI removable media binary efi/boot/bootarm.efi >>>>>> Scanning disks on usb... >>>>>> Disk usb0 not ready >>>>>> Disk usb1 not ready >>>>>> Disk usb2 not ready >>>>>> Disk usb3 not ready >>>>>> Scanning disks on mmc... >>>>>> MMC Device 1 not found >>>>>> MMC Device 2 not found >>>>>> MMC Device 3 not found >>>>>> Found 3 disks >>>>>> 508704 bytes read in 26 ms (18.7 MiB/s) >>>>>> ## Starting EFI application at 42000000 ... >>>>>> Consoles: EFI console >>>>>> failed to allocate staging area: 14 >>>>>> failed to allocate staging area >>>>>> ## Application terminated, r = 5 >>>>>> EFI LOAD FAILED: continuing... >>>>>> >>>>>> >>>>>> Tried manually loading ubldr.bin: >>>>>> >>>>>> => fatload mmc 0 0x42000000 ubldr.bin >>>>>> 306972 bytes read in 15 ms (19.5 MiB/s) >>>>>> => go 0x42000000 >>>>>> Loading kernel... >>>>>> /boot/kernel/kernel text=0x85d7f0 data=0xaf620+0x24e1e0 >>>>>> syms=[0x4+0xa87d0+0x4+0x10c603] >>>>>> Loading configured modules... >>>>>> /boot/kernel/umodem.ko text=0x1bf4 text=0x1320 data=0x1080+0xf88 >>>>>> syms=[0x4+0x1070+0x4+0xbcd] >>>>>> loading required module 'ucom' >>>>>> /boot/kernel/ucom.ko text=0x1f8c text=0x2e90 data=0x1080+0x17bc >>>>>> syms=[0x4+0x14f0+0x4+0xc5d] >>>>>> Could not load one or more modules! >>>>>> >>>>>> Hit [Enter] to boot immediately, or any other key for command prompt. >>>>>> Booting [/boot/kernel/kernel]... >>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333 >>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >>>>>> Kernel entry at 0x42400180... >>>>>> Kernel args: (null) >>>>>> >>>>>> And then it reboots... >>>>>   I've just re-introduce the cache patches for u-boot as it >>>>> appears that >>>>> some boards needs them (I've probably tested the wrong unpatched >>>>> u-boot >>>>> when I removed them ...) so booting with ubldr.bin should work now. >>>>>   For the EFI issue I don't really know what is happening. >>>> >>>> Thanks! With the updated U-boot it now boots with ubldr.bin. >>>> >>>> How can I make it do this automatically? >>>  If you copy the boot.scr file from the port/package to the root of the >>> fat partition this will load ubldr.bin directly. >> >> Thanks again! It works! >> >> >>>  I'm more interested to debug the efi problem, I'll try on a H2 board. >> >> If there is anything I can do to help let me know. >> >> I tried with boot1.efi as /efi/boot/bootarm.efi: >> >> ## Starting EFI application at 42000000 ... >> >> FreeBSD EFI boot block >>    Loader path: /boot/loader.efi >> >>    Initializing modules: UFS >>    Load Path: /\efi\boot\bootarm.efi >>    Load Device: >> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x800,0x2000) >>    Probing 3 block devices.....* done >>     UFS found 1 partition >> Consoles: EFI console >> failed to allocate staging area: 14 >> failed to allocate staging area >> Failed to start image provided by UFS (5) >> panic: No bootable partitions found! >> ## Application terminated, r = 1 >> EFI LOAD FAILED: continuing… > > shot in the dark: > I found out that if the root partition is not freebsd-ufs the efi boot > failed. > do a gpart show, > > mine looks like this: > neo-001> gpart show > =>      63  15523777  mmcsd0  MBR  (7.4G) >        63      1985          - free -  (993K) >      2048    102400       1  fat32lba  [active]  (50M) >    104448   6187008       2  freebsd  (3.0G) >   6291456   9232384          - free -  (4.4G) > > =>      0  6187008  mmcsd0s2  BSD  (3.0G) >        0  6187008         1  freebsd-ufs  (3.0G) Nope, mine looks almost the same: =>      63  31116225  mmcsd0  MBR  (15G)         63      1985          - free -  (993K)       2048      8192       1  fat16  (4.0M)      10240      6144          - free -  (3.0M)      16384   4177920       2  freebsd  (2.0G)    4194304  26921984          - free -  (13G) =>      0  4177920  mmcsd0s2  BSD  (2.0G)         0  4177920         1  freebsd-ufs  (2.0G) Interestingly, loading bootarm.efi(boot1.efi) manually gets me to the loader: => fatload mmc 0 0x42000000 efi/boot/bootarm.efi 39500 bytes read in 4 ms (9.4 MiB/s) => bootefi 0x42000000 But it does not boot: Type '?' for a list of commands, 'help' for more detailed help. OK load boot/kernel/kernel boot/kernel/kernel text=0x89ef08 data=0xae620+0x1f5aa0 syms=[0x4+0xa6d30+0x4+0x109e65] OK load -t dtb boot/dtb/sun8i-h2-plus-orangepi-r1.dtb boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333 OK boot Using DTB from loaded file 'boot/dtb/sun8i-h2-plus-orangepi-r1.dtb'. EHCI failed to shut down host controller. Kernel entry at 0x43000180... Kernel args: (null) modulep: 0xc0d03000 relocation_offset 0 --Hangs here-- From owner-freebsd-arm@freebsd.org Mon Sep 3 08:21:18 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 388B2FE22E6 for ; Mon, 3 Sep 2018 08:21:18 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B98327AEBF for ; Mon, 3 Sep 2018 08:21:17 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 6CE8AFE22E5; Mon, 3 Sep 2018 08:21:17 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 298CCFE22E4 for ; Mon, 3 Sep 2018 08:21:17 +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 864037AEBA for ; Mon, 3 Sep 2018 08:21:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1fwk6f-0008pA-Rk; Mon, 03 Sep 2018 11:21:09 +0300 From: Daniel Braniss Message-Id: <855C0010-888D-4988-8056-7788CBCF5A48@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: allwinner/nanopi neo boot issues Date: Mon, 3 Sep 2018 11:21:09 +0300 In-Reply-To: Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" To: Jakob Alvermark References: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> <0fdbd315-f37d-e3d3-9309-612f53c4d379@alvermark.net> <8459A9BA-183A-461B-9050-3631C51218F9@cs.huji.ac.il> <474af48e-ba82-62ce-34a3-70dfc4382723@alvermark.net> <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> <03d4cb0a-c218-a186-936d-765261da2775@alvermark.net> <20180902172444.c4911c8c65a99a7d5e9fe8fa@bidouilliste.com> <4410f41b-79f5-f397-b0b1-84bceae82bd0@alvermark.net> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 08:21:18 -0000 > On 3 Sep 2018, at 11:05, Jakob Alvermark wrote: >=20 >=20 > On 9/3/18 9:01 AM, Daniel Braniss wrote: >>=20 >>=20 >>> On 2 Sep 2018, at 19:33, Jakob Alvermark > wrote: >>>=20 >>> On 9/2/18 5:24 PM, Emmanuel Vadot wrote: >>>> On Sun, 2 Sep 2018 17:14:10 +0200 >>>> Jakob Alvermark > = wrote: >>>>=20 >>>>> On 9/1/18 10:46 PM, Emmanuel Vadot wrote: >>>>>> On Sat, 1 Sep 2018 15:50:25 +0200 >>>>>> Jakob Alvermark > wrote: >>>>>>=20 >>>>>>> On 8/29/18 2:22 PM, Daniel Braniss wrote: >>>>>>>>> On 29 Aug 2018, at 15:17, Jakob Alvermark >>>>>>>>> >> = wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 8/24/18 10:02 AM, Daniel Braniss wrote: >>>>>>>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss = >>>>>>>>>>> >> = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> hi, >>>>>>>>>>> with the latest current r338243 no longer boots via ubldr, = efi does >>>>>>>>>>> but with overlays I have to manually enter the root = partition. >>>>>>>>>>>=20 >>>>>>>>>>> this is where it hangs via ubldr: >>>>>>>>>>>=20 >>>>>>>>>>> Autoboot in 8 seconds, hit [Enter] to boot or any other key = to stop >>>>>>>>>>>=20 >>>>>>>>>>> Loading kernel... >>>>>>>>>>> /boot/kernel/kernel text=3D0x8a0950 data=3D0xae160+0x184520 >>>>>>>>>>> syms=3D[0x4+0xa6d70+0x4+0x109f17] >>>>>>>>>>> Loading configured modules... >>>>>>>>>>> /boot/entropy size=3D0x1000 >>>>>>>>>>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x601b >>>>>>>>>>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. >>>>>>>>>>> Kernel entry at 0x42400180... >>>>>>>>>>> Kernel args: (null) >>>>>>>>>>>=20 >>>>>>>>>>> older - r337232 - boots fine, >>>>>>>>>>>=20 >>>>>>>>>>> any ideas where to look? >>>>>>>>>> should have done an update before writing! >>>>>>>>>>=20 >>>>>>>>>> with the latest (and greatest) all is back to normal! >>>>>>>>>> so now on to test orange pi one(h3), nanopi neo 2 (h5) and = nanopi >>>>>>>>>> neo a64 >>>>>>>>>>=20 >>>>>>>>>> thanks, >>>>>>>>>> danny >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I am trying to get an Orange Pi R1 going, I get the same. >>>>>>>>>=20 >>>>>>>>> Loading kernel... >>>>>>>>> /boot/kernel/kernel text=3D0x89ee40 data=3D0xae620+0x1f5ba0 >>>>>>>>> syms=3D[0x4+0xa6d20+0x4+0x109e51] >>>>>>>>> Loading configured modules... >>>>>>>>> Could not load one or more modules! >>>>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 >>>>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >>>>>>>>> Kernel entry at 0x42400180... >>>>>>>>> Kernel args: (null) >>>>>>>>>=20 >>>>>>>>> This is at r338369. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>> try booting via efi; >>>>>>>> make sure to copy /boot/loader.efi to = /boot/msdos/EFI/BOOT/bootaa64.efi >>>>>>>> remove /boot/msdos/boot.scr >>>>>>>> good luck, >>>>>>>> danny >>>>>>> I tried the ALPHA4 snapshot, this happens: >>>>>>>=20 >>>>>>> Hit any key to stop autoboot: 0 >>>>>>> switch to partitions #0, OK >>>>>>> mmc0 is current device >>>>>>> Scanning mmc 0:1... >>>>>>> 25395 bytes read in 4 ms (6.1 MiB/s) >>>>>>> Found EFI removable media binary efi/boot/bootarm.efi >>>>>>> Scanning disks on usb... >>>>>>> Disk usb0 not ready >>>>>>> Disk usb1 not ready >>>>>>> Disk usb2 not ready >>>>>>> Disk usb3 not ready >>>>>>> Scanning disks on mmc... >>>>>>> MMC Device 1 not found >>>>>>> MMC Device 2 not found >>>>>>> MMC Device 3 not found >>>>>>> Found 3 disks >>>>>>> 508704 bytes read in 26 ms (18.7 MiB/s) >>>>>>> ## Starting EFI application at 42000000 ... >>>>>>> Consoles: EFI console >>>>>>> failed to allocate staging area: 14 >>>>>>> failed to allocate staging area >>>>>>> ## Application terminated, r =3D 5 >>>>>>> EFI LOAD FAILED: continuing... >>>>>>>=20 >>>>>>>=20 >>>>>>> Tried manually loading ubldr.bin: >>>>>>>=20 >>>>>>> =3D> fatload mmc 0 0x42000000 ubldr.bin >>>>>>> 306972 bytes read in 15 ms (19.5 MiB/s) >>>>>>> =3D> go 0x42000000 >>>>>>> Loading kernel... >>>>>>> /boot/kernel/kernel text=3D0x85d7f0 data=3D0xaf620+0x24e1e0 >>>>>>> syms=3D[0x4+0xa87d0+0x4+0x10c603] >>>>>>> Loading configured modules... >>>>>>> /boot/kernel/umodem.ko text=3D0x1bf4 text=3D0x1320 = data=3D0x1080+0xf88 >>>>>>> syms=3D[0x4+0x1070+0x4+0xbcd] >>>>>>> loading required module 'ucom' >>>>>>> /boot/kernel/ucom.ko text=3D0x1f8c text=3D0x2e90 = data=3D0x1080+0x17bc >>>>>>> syms=3D[0x4+0x14f0+0x4+0xc5d] >>>>>>> Could not load one or more modules! >>>>>>>=20 >>>>>>> Hit [Enter] to boot immediately, or any other key for command = prompt. >>>>>>> Booting [/boot/kernel/kernel]... >>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 >>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >>>>>>> Kernel entry at 0x42400180... >>>>>>> Kernel args: (null) >>>>>>>=20 >>>>>>> And then it reboots... >>>>>> I've just re-introduce the cache patches for u-boot as it = appears that >>>>>> some boards needs them (I've probably tested the wrong unpatched = u-boot >>>>>> when I removed them ...) so booting with ubldr.bin should work = now. >>>>>> For the EFI issue I don't really know what is happening. >>>>>=20 >>>>> Thanks! With the updated U-boot it now boots with ubldr.bin. >>>>>=20 >>>>> How can I make it do this automatically? >>>> If you copy the boot.scr file from the port/package to the root of = the >>>> fat partition this will load ubldr.bin directly. >>>=20 >>> Thanks again! It works! >>>=20 >>>=20 >>>> I'm more interested to debug the efi problem, I'll try on a H2 = board. >>>=20 >>> If there is anything I can do to help let me know. >>>=20 >>> I tried with boot1.efi as /efi/boot/bootarm.efi: >>>=20 >>> ## Starting EFI application at 42000000 ... >>> >> FreeBSD EFI boot block >>> Loader path: /boot/loader.efi >>>=20 >>> Initializing modules: UFS >>> Load Path: /\efi\boot\bootarm.efi >>> Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x80= 0,0x2000) >>> Probing 3 block devices.....* done >>> UFS found 1 partition >>> Consoles: EFI console >>> failed to allocate staging area: 14 >>> failed to allocate staging area >>> Failed to start image provided by UFS (5) >>> panic: No bootable partitions found! >>> ## Application terminated, r =3D 1 >>> EFI LOAD FAILED: continuing=E2=80=A6 >>=20 >> shot in the dark: >> I found out that if the root partition is not freebsd-ufs the = efi boot failed. >> do a gpart show, >>=20 >> mine looks like this: >> neo-001> gpart show >> =3D> 63 15523777 mmcsd0 MBR (7.4G) >> 63 1985 - free - (993K) >> 2048 102400 1 fat32lba [active] (50M) >> 104448 6187008 2 freebsd (3.0G) >> 6291456 9232384 - free - (4.4G) >>=20 >> =3D> 0 6187008 mmcsd0s2 BSD (3.0G) >> 0 6187008 1 freebsd-ufs (3.0G) >=20 > Nope, mine looks almost the same: >=20 > =3D> 63 31116225 mmcsd0 MBR (15G) > 63 1985 - free - (993K) > 2048 8192 1 fat16 (4.0M) > 10240 6144 - free - (3.0M) > 16384 4177920 2 freebsd (2.0G) > 4194304 26921984 - free - (13G) >=20 > =3D> 0 4177920 mmcsd0s2 BSD (2.0G) > 0 4177920 1 freebsd-ufs (2.0G) >=20 > Interestingly, loading bootarm.efi(boot1.efi) manually gets me to the = loader: >=20 >=20 bootarm.efi should be a copy of loader.efi not boot1.efi as far as I = know. > =3D> fatload mmc 0 0x42000000 efi/boot/bootarm.efi > 39500 bytes read in 4 ms (9.4 MiB/s) > =3D> bootefi 0x42000000 > But it does not boot: >=20 > Type '?' for a list of commands, 'help' for more detailed help. > OK load boot/kernel/kernel > boot/kernel/kernel text=3D0x89ef08 data=3D0xae620+0x1f5aa0 = syms=3D[0x4+0xa6d30+0x4+0x109e65] > OK load -t dtb boot/dtb/sun8i-h2-plus-orangepi-r1.dtb =20 > boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 > OK boot > Using DTB from loaded file 'boot/dtb/sun8i-h2-plus-orangepi-r1.dtb'. > EHCI failed to shut down host controller. > Kernel entry at 0x43000180... > Kernel args: (null) > modulep: 0xc0d03000 > relocation_offset 0 > --Hangs here-- From owner-freebsd-arm@freebsd.org Mon Sep 3 12:42:15 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 783BFFE89EA for ; Mon, 3 Sep 2018 12:42:15 +0000 (UTC) (envelope-from zrahimkhani2014@gmail.com) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E0FF88321A for ; Mon, 3 Sep 2018 12:42:14 +0000 (UTC) (envelope-from zrahimkhani2014@gmail.com) Received: by mail-lj1-x241.google.com with SMTP id p6-v6so365143ljc.5 for ; Mon, 03 Sep 2018 05:42:14 -0700 (PDT) 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=+fvlZM3vqUWXnc1dSY7A3reDNmlTwTj+557JNQEW+tY=; b=vDPgYk9oQF6GOgH5Ohoeby1BSvop7/DOhf6wabVBiwfwnSBQQ69/yW0/ZC3vGpbNkB tLOIeaXpuLkRbnsYIrOzYPZll3lmuzyEjWBmis3H9t/8lLDnbcy9n1y5qY4+b16davLd IeWUtRw0kghfrhMEXHrLKkPWU9hVUVndogh4GOFtErAbvhZ9hwFUQqsoaRTl70rfGrMq 4KFsCIVX/MsSPSWtH2kab6ZGcnjxHMD0/c6oQthmbwJ6g1IvbOnjPriTUWxngVd5iF1N u9TDVvFTb3kcn4hXKC/AiDPuWarbEtLGPwEWjMlVLnCMuLvcGY0c8v0e3T5w7pAqFMJo GTvw== 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=+fvlZM3vqUWXnc1dSY7A3reDNmlTwTj+557JNQEW+tY=; b=hIiBwY8hm7JoHu3kT8FSJcAedZWZ70GsmphMbBH0FrWR9DJy3rUEBVkmWh7SuKXi7A 44dOBke+s9UmgSkJM7UCcKxGm7JL0b5dM3aOvzbHgrc1s9IF/PKteVHNPQ8eXYOIXpGO fB7dkGj/obS9KtSvPpb3fkDSI3lfniilu1S1618FpdPPLJhHoT90QAhPC6kOnlub2c6Q bym2tpFNKlbVWtXdDG+DKGdvPLYbb1IyTUYL0uKNFNt++cKWfVx/2mGPIcsvXbORLEUT 2xhD5zxiOG07DHkfn783qqIZ12xAgHD/S8xwMWnIN150RZBgSpOKC/tktXSd3lIEECbl Iahw== X-Gm-Message-State: APzg51AZ37Jzk37ne+Q8TzOkvBGRMNd+pRfjCCAM/xs9aeM4gLDnkbDL Q3nM9sWATgmTn7AbQLHzKRsmw+bGJT4oIbS3eZLH6cptU6A= X-Google-Smtp-Source: ANB0VdYQPiAbwKilcCn1awXFAD6Z0F8KaNVGbyyhSqPMCpd3sgT1ZzPMTkzVb3YsmI77W2icK0SMT1It987z1jT/VrE= X-Received: by 2002:a2e:8103:: with SMTP id d3-v6mr9050743ljg.3.1535978532768; Mon, 03 Sep 2018 05:42:12 -0700 (PDT) MIME-Version: 1.0 From: zahra rahimkhani Date: Mon, 3 Sep 2018 12:42:08 +0430 Message-ID: Subject: a hardware problem raspberries pi3 model B To: freebsd-arm@freebsd.org X-Mailman-Approved-At: Mon, 03 Sep 2018 13:16:40 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 12:42:15 -0000 Hello friends, I have a raspberries pi3 model B that have a hardware problem in the serial port and HDMI. Could you explain to me How to solve it? or is a way that sees the output ? Best wishes, Zahra From owner-freebsd-arm@freebsd.org Mon Sep 3 14:46:24 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8128FFEC2CA for ; Mon, 3 Sep 2018 14:46:24 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A1988838D for ; Mon, 3 Sep 2018 14:46:23 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: dd068933-af85-11e8-9234-0d515945242e X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id dd068933-af85-11e8-9234-0d515945242e; Mon, 03 Sep 2018 14:30:11 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w83EUABY026879; Mon, 3 Sep 2018 08:30:10 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1535985010.9486.44.camel@freebsd.org> Subject: Re: utility for pin in BBB: PX.Y --> pin_mode, pin_name From: Ian Lepore To: Nicola Mingotti Cc: freebsd-arm Date: Mon, 03 Sep 2018 08:30:10 -0600 In-Reply-To: References: <4661fc41-935a-56d5-2cc2-125085daf30a@gmail.com> <1535568374.33841.47.camel@freebsd.org> <1535576856.33841.58.camel@freebsd.org> <1535643488.33841.74.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 14:46:24 -0000 On Mon, 2018-09-03 at 08:21 +0200, Nicola Mingotti wrote: > > On 08/30/18 17:38, Ian Lepore wrote: > > > > On Wed, 2018-08-29 at 23:40 +0200, Nicola Mingotti wrote: > > > > > > On 08/29/18 23:07, Ian Lepore wrote: > > > > > > > > On Wed, 2018-08-29 at 22:26 +0200, Nicola Mingotti wrote: > > > > > > > > > > On 08/29/18 20:46, Ian Lepore wrote: > > > > > > > > > > > > On Wed, 2018-08-29 at 20:01 +0200, Nicola Mingotti wrote: > > > > > > > > > > > > > > Thank you for suggestion Russel, > > > > > > > > > > > > > > but unfortunately, at best of my knowldege, > > > > > > > $> man 3 gpio_open > > > > > > > and its shell command brother > > > > > > > $> man 8 gpioctl > > > > > > > > > > > > > > are not appropriate, they are useful only if a pin > > > > > > > has been configured as GPIO pin. > > > > > > > > > > > > > > The program i look for would be useful instead to > > > > > > > esablish > > > > > > > which physical pin has been configured as GPIO pin or > > > > > > > PWM, PRU, I2C etc. > > > > > > > > > > > > > > I asked also in the Forum, but the only one aswering > > > > > > > (@Phishry) has given me your same suggestion. > > > > > > > > > > > > > > If nobody knows of such a program i will start the > > > > > > > implementation, > > > > > > > maybe > > > > > > > tomorrow. > > > > > > > > > > > > > > bye > > > > > > > Nicola > > > > > > > > > > > > > Please bottom-post when replying to freebsd mailing lists. > > > > > ok ! > > > > > > > > > > > > There is no interface defined for getting an fdt_pinctrl > > > > > > driver > > > > > > to > > > > > > return info about the current configuration. Even if such > > > > > > an > > > > > > interface > > > > > > existed, there would also need to be a new driver providing > > > > > > a > > > > > > cdev > > > > > > so > > > > > > that userland can access the information. > > > > > ok, no interface. > > > > > > > > > > > > There is also nothing in freebsd equivelent to the linux > > > > > > devmem2 > > > > > > program. A driver would have to be written to provide > > > > > > access to > > > > > > device- > > > > > > mapped memory before such a program could be written. You > > > > > > can't > > > > > > access > > > > > > arm hardware registers via /dev/mem or /dev/kmem. > > > > > > > > > > > > -- Ian > > > > > I just compiled devmem2 and it seems to work. I did silly > > > > > modifications. > > > > > The code is here: http://euriscom.it/data/dm2.c > > > > > (forget the first comment lines, they are poor, I did not > > > > > intend > > > > > to > > > > > share this, it is my working copy) > > > > > > > > > > if i run it: > > > > > --------------------------------- > > > > > #> ./dm2 0x44e10998 b > > > > > /dev/mem opened. > > > > > Memory mapped at address 0x20221000. > > > > > Value at address 0x44E10998 (0x20221998): 0x5 > > > > > --------------------------------- > > > > > > > > > > Whic corresponds to what i wrote in the DTO. > > > > > ----- > > > > >               pru_pru_pins: pinmux_pru_pru_pins { > > > > >                          pinctrl-single,pins = < > > > > >                              // 0x1a4 0x05   /* P9.27 > > > > > pr1_pru0_pru_r30_5, > > > > > Mode 5 output pull-down   */ > > > > >                              0x19c 0x26   /* P9.28 > > > > > pr1_pru0_pru_r31_3, > > > > > Mode 6 input pull-down    */ > > > > >                              0x198 0x05    /* PRU0-2 -- P9.30 > > > > > -- > > > > > pr1_pru0_pru_r30_2 ... se in MODE-5  */ > > > > >                              >; > > > > >                      }; > > > > > ----- > > > > > > > > > > This is the only test i made but it seems improbable I got > > > > > the > > > > > same > > > > > value by chance;) > > > > > > > > > > It goes without saying that I don't understand all what i > > > > > wrote, > > > > > so, i could be boldly wrong ;) > > > > > > > > > > If it turns out it works let me know, i can make the port. > > > > > > > > > > bye > > > > > n. > > > > You might accidentally get /dev/mem access to work, but it's > > > > not by > > > > design. The rules of the arm memory model forbid mapping the > > > > same > > > > physical memory to different virtual addresses using different > > > > attributes (normal cacheable memory versus Device memory), and > > > > I > > > > don't > > > > see anything in the arm devmem code that handles memory > > > > attributes. > > > > > > > > -- Ian > > > I would like to discuss more this thing but really, i am too > > > ignorant > > > on > > > this subject. > > > > > > What i can say is this, I learnt to use devmem2 from D.Molloy > > > book > > > "Exploring BeagleBone", > > > see pg. 218. The author says this way "bypasses the Linux OS". I > > > used > > > the thing > > > in Linux, it works, as it seems to do in FreeBSD-12-APLHA. > > > > > > If can tell you also I remember i used it one day in FreeBSD- > > > 11.1, > > > it > > > was working. > > > > > > I don't have the background to go deeper. > > > > > > If you can understand why it works and establish that it is > > > realiable > > > (even only for reading) let me (us) know ! ;) > > > > > > bye > > > n. > > > > > I think it should be possible to do a bit of kernel work to change > > it > > from "works by accident" to "does the right thing", except I'm not > > sure > > it'll be possible to automatically detect when Device memory is > > being > > accessed/mapped. It may be necessary to use the mem(4) ioctls to > > set > > the region to MDF_UNCACHEABLE, or even better, define a new > > MDF_MMIO > > for mapping ranges of device registers that arm systems have to > > treat > > as memory type Device. I'll look into it when I have some time. > > > > -- Ian > Hi, > > After a suggestion from @Phisfry on the forum I guess found a way > to bypass the need of devmem2 to write my "pinfunc" utlity. > > I can read (all?) pin configurations from "ofwdump -a -p", indeed I > see  > blocks > like this: > ---------------------- > #> ofwdump -a -p > ---------- >    Node 0x30f4: pinmux_ehrpwm0_AB_pins >              phandle: >                00 00 00 ce >              pinctrl-single,pins: >                00 00 01 54 00 00 00 03 00 00 01 50 00 00 00 03 > ---------- > > So I hopefully wrote my script to parse "ofwdump" and what i got is > this, > > -------------------------- > #> pinfunc.rb > HEADER   NAME            MODE       FUNCTION > ... > P.9.10   SYS_RESETn      1          - > P.9.11   UART4_RXD       not-found > P.9.12   GPIO1_28        not-found > P.9.13   UART4_TXD       not-found > P.9.14   EHRPWM1A        not-found > P.9.15   GPIO1_16        not-found > P.9.16   EHRPWM1B        not-found > P.9.17   I2C1_SCL        not-found > P.9.18   I2C1_SDA        not-found > P.9.19   I2C2_SCL        3          I2C2_SCL > P.9.20   I2C2_SDA        3          I2C2_SDA > P.9.21   UART2_TXD       3          ehrpwm0B > P.9.22   UART2_RXD       3          ehrpwm0A > P.9.23   GPIO1_17        not-found > P.9.24   UART1_TXD       not-found > P.9.25   GPIO3_21        0          mcasp0_ahclkx > P.9.26   UART1_RXD       not-found > P.9.27   GPIO3_19        not-found > P.9.28   SPI1_CS0        6          pr1_pru0_pru_r31_3 > P.9.29   SPI1_D0         0          mcasp0_fsx > P.9.30   SPI1_D1         6          pr1_pru0_pru_r31_2 > P.9.31   SPI1_SCLK       0          mcasp0_aclkx > P.9.32   VADC > ... > --------------------------- > > The only isssue seems to be that GPIO pins do not appear. > I could fix the problem parsing the output of "gpioctl -f /dev/gpioX/ > -l" > > But I have a couple of questions : > 1] Is there somewhare written the GPIO pins configuration in > "ofwdump" ? > 2] If it is not written there, what is the reason ? > 2.1] Where is the boot GPIO pins configuration written ? > 2.2] I looked also in "dtc -I dtb -O dts /boot/dtb/am335x- > boneblack.dtb  > > > > less" > but at the best of my ability to read it I could not find the GPIOs  > configuration. > > bye > nico The pinctrl info in the fdt data is used to override pins from their default settings that the chip powers on with. So you have to start with empirical knowledge of that, and treat the fdt data as a set of modifications to it. Obviously the pin defaults are different for every soc. In theory, the pinctrl data is not static, it can be changed at runtime. In practice, that rarely happens, and could only happen if the node has multiple pinctrl-N properties so that the drivers can switch between them. Rather than parsing the ascii output from ofwdump (a program that's hard to love in any way), you'd probably be better off reading the actual binary data (sysctl -b hw.fdt.dtb | yourprog), and parse it using libfdt. Hmm, do we distribute libfdt? I think not. It should at least be a port even if it's not licensed properly to be distributed with the base system. -- Ian From owner-freebsd-arm@freebsd.org Mon Sep 3 15:08:31 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35605FECA7D for ; Mon, 3 Sep 2018 15:08:31 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD29A88F77 for ; Mon, 3 Sep 2018 15:08:30 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 35e4417c-af8b-11e8-9234-0d515945242e X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 35e4417c-af8b-11e8-9234-0d515945242e; Mon, 03 Sep 2018 15:08:28 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w83F8RPs026951; Mon, 3 Sep 2018 09:08:27 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1535987307.9486.47.camel@freebsd.org> Subject: Re: utility for pin in BBB: PX.Y --> pin_mode, pin_name From: Ian Lepore To: Nicola Mingotti Cc: freebsd-arm Date: Mon, 03 Sep 2018 09:08:27 -0600 In-Reply-To: <1535985010.9486.44.camel@freebsd.org> References: <4661fc41-935a-56d5-2cc2-125085daf30a@gmail.com> <1535568374.33841.47.camel@freebsd.org> <1535576856.33841.58.camel@freebsd.org> <1535643488.33841.74.camel@freebsd.org> <1535985010.9486.44.camel@freebsd.org> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 15:08:31 -0000 On Mon, 2018-09-03 at 08:30 -0600, Ian Lepore wrote: > On Mon, 2018-09-03 at 08:21 +0200, Nicola Mingotti wrote: > > > > > > > [...] > Hmm, do we distribute libfdt? I think not. It should at > least be a port even if it's not licensed properly to be distributed > with the base system. > Answering my own question... right now, we do not. The library has a BSD license, so IMO we should distribute it. There is an old neglected open review for doing so, applying the patches from it would add libfdt to the base system. https://reviews.freebsd.org/D6814 -- Ian From owner-freebsd-arm@freebsd.org Mon Sep 3 15:13:21 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C2D0FECC79 for ; Mon, 3 Sep 2018 15:13:21 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2491892D5 for ; Mon, 3 Sep 2018 15:13:20 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-pg1-x543.google.com with SMTP id x26-v6so313518pge.12 for ; Mon, 03 Sep 2018 08:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=WHybc7T4A6TGNpvI38a8S1xuDUwiR1NwVZNAvbKTm2g=; b=Ei6EzeAY4dLrxAAz3MwCNCw/zAr2rnlA5u9kJL9GcZ1LA8eUxDm0HcIkUDjW9UrSMc cixZ+aVh4l734cUkF44+tdeBivXJxYSStZHQNxKudenms0syAeiPp1vJAS7qrkHw6KYP tErq8bgBmrNtid59Q0KHv0NYhR9NqhMF2sMtdVVFqQI4NIoUwmFyXlhcLeL04/R31Mxp hegPKVm+w/zJrpBHqGJbReneltChQr2ev96jwQzAAj1uEs2XecojcgZsl2rIy4wtL0nC Tr2bRZ+AbTwmZJq34fo4rYFm4yXnsB9GiGIOmufsdne87nZlPK5EoMp6lrVnz98dfB4G Fqjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=WHybc7T4A6TGNpvI38a8S1xuDUwiR1NwVZNAvbKTm2g=; b=Et/yK4ZnNkyAM+/WGUFuwRtB0W5Buz9P07cqMhqw6SVpdRA5Ohe0uMF0NrY4guYIIk PUyKIJL7p/9qkdnjwKP7i+LhooyeOMNGBDTwVQ14HOfcsfyeY139xZCc7eigqvZ0q1pI DIV29gmyzHoc3Rf3Us+Kf5e0ah2SceYdtIbfM/khZMJ/tab2MeAtuhZibXZ7xwD/+XA4 PfoOqT5FcxeWmOxU7MCqk4TW3QRj6+LYTopNfRHyCC/qpctfGucRP5Muk6zHvO8isMZr p0jKwSRodSuEiN5MZkFVhJsjNpV8440UBcY5iBMy6IPgzif0/T677of5k/Uh1rngUt3/ Svrg== X-Gm-Message-State: APzg51CYp59/K/ywsV9Me9ix+tRK4Le0FpSRY+lvtMkvaF0dCOmp1sGK ADEOvGVESan/L0qzqF0U+82PO4jauM5Mmw== X-Google-Smtp-Source: ANB0VdZ4IEgcMZ8H2m8sHd7MMfCSSnZBIVVRNdXTnUOKiLm49O8FLgCtKAqD+PN0veRBEgqkMhtR6w== X-Received: by 2002:a63:e756:: with SMTP id j22-v6mr26939278pgk.185.1535987599503; Mon, 03 Sep 2018 08:13:19 -0700 (PDT) Received: from mutt-hbsd (relay1.tor.openinternet.io. [62.210.129.246]) by smtp.gmail.com with ESMTPSA id u25-v6sm26781992pfk.177.2018.09.03.08.13.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 08:13:18 -0700 (PDT) Date: Mon, 3 Sep 2018 11:12:19 -0400 From: Shawn Webb To: zahra rahimkhani Cc: freebsd-arm@freebsd.org Subject: Re: a hardware problem raspberries pi3 model B Message-ID: <20180903151219.tfopetpgyv2rsahg@mutt-hbsd> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="n6drrkubg7hknlhc" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD mutt-hbsd 12.0-ALPHA3 FreeBSD 12.0-ALPHA3 X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20180622 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 15:13:21 -0000 --n6drrkubg7hknlhc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 03, 2018 at 12:42:08PM +0430, zahra rahimkhani wrote: > Hello friends, >=20 > I have a raspberries pi3 model B that have a hardware problem in the seri= al > port and HDMI. > Could you explain to me How to solve it? > or is a way that sees the output ? What version of FreeBSD are you using? If you're using 12-CURRENT, then you now need to put in /boot/loader.conf: boot_serial=3D"YES" boot_multicons=3D"YES" Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --n6drrkubg7hknlhc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAluNT08ACgkQaoRlj1JF bu7Xkg/+ICmEyBBGPwHjEJzRno1MJXLuC0zdrPvnj5eARMmhMTf7U8ZkVMWsaIOB PT5LUnLpQj2CggGea51qFtshSF0br+xjNat73eZ8btQBXie/ETAishKWySyGzk4k H5L/O9xnS+KZ0NaNQO0X78M9n1m7mWcU9xqb6xokejHbmsfmkAlv70GC98ReOE45 XqP61CkPU7g4ydRedEIcYbHQxbaQzqznzyajk9Wv3P7A3Lyg8ytog3gnoJNcY+Pk XkytnwRc4Si2OTb60f1qcY9is0/JoGEyIwg8s34g3hx4Eif75GD36c2BiP4RMVjF IdNeVZiV9WN6HSApn/VJWZGxpoJsVhMlh2EoTvsvy8dyAmPKckAc26/CPPVaSc/X CfCDuqpHqth2OnhQIlo+ho5OtqHKXqcbozjYOGDtKcfDHNeflV03UcfT91p9GMkS rTkxoEmMR9NrvGo5DBUVOFGYeQmbMtxmqyorlho7t0jQmARirtdeWnH3Hm8OphHD LtRoN8SEgG+cbrgH+K+IuMjoWveEB9gNo92EZUrHNUiY2qKmjguJFbac+CedZH++ QM53vP6qu/UrVCf3zLrKy090y7rZrRIaROsVsoRw+qDmBxbD0lSvskGzDgQqs5Gi kQVvtWTLwM+LhIzUN6m2Gw51SjcCTsbCKtFMKVJjZXyOwz2Nc08= =Id5J -----END PGP SIGNATURE----- --n6drrkubg7hknlhc-- From owner-freebsd-arm@freebsd.org Mon Sep 3 15:32:15 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 143A7FED074 for ; Mon, 3 Sep 2018 15:32:15 +0000 (UTC) (envelope-from zrahimkhani2014@gmail.com) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79E9689AED for ; Mon, 3 Sep 2018 15:32:14 +0000 (UTC) (envelope-from zrahimkhani2014@gmail.com) Received: by mail-lj1-x241.google.com with SMTP id s12-v6so806479ljj.0 for ; Mon, 03 Sep 2018 08:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kvl6g3RFq4tMdtdxG3mv6fJsqugbBtMTPSMk2Y2W6OI=; b=ugME702aMB/L1Fys7eGc6cugygHdBtpVHbGQSdykkev3ug07Qk4qTSsFRNoZ5cvOii K3INgdMPAzVD885oPufB3OA0bR0oCgFk4cV5jyuohb5MCUrIF98fgiWB/WMiUeq8MxQA Ho6w4uHEIE7+oR0M5YVlF9oQfd/R+y/rRxYdmkQ+p4OTWsoxkluJfdnQ9aYxLLFhJFJv 4TlN4eZXdO8Nc9RKCKosZXleYMdNG1o349jtmlBbjzxjI8aafZ5+irzFho0KHRi4aA38 WWW1tZnvsxTL6vPj7e+Xg2FjJEmRxLVwE0yYmejrjVInNrlhp3HRzmbTdmuiHb0DdKSX vXCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kvl6g3RFq4tMdtdxG3mv6fJsqugbBtMTPSMk2Y2W6OI=; b=Md6ccP2VbdJ6lIMEGzDHuBIYSnbgJuNyz2wqR/BpW4Fss0lE5k6FxkdaLfK/03eveW Ic0zFjbDWh3tWH46BJpBq8aZfPDxP/MgxMTfq6+ZgENJZIfWdHA1KtIjA2YJMsUwuKSM SLzXKKSwLC7Sg9ue110Z4/LQD15Q2ljbEhHBv2yctuuJb6CJ92aePs59UHzX28ykicG8 wsDrw+7Eop6lih17Y+1gb2ISpcGekq9pOi5bQ5btBgDCawKXyg1m3YBGiNHBXx9wRFio 9yLMOfJR80KCRKFhDECLWV0LhYI9Y8jz+gHdFkfgcR34+L56hh93rf0UN1Ucar+aTB7L vOpg== X-Gm-Message-State: APzg51DvcY1KmqVsc5XHak8nDJjPLbBTgk3LmaOkoTzuPi6K16N6oq+U itM60+TPZCh5fvnDVjJWPtMPZMp8Tef+TiEn+VBLt3+bpcY= X-Google-Smtp-Source: ANB0VdYqhAkdpLEbnS0KjSgzDJ/rDKQfQq6OpFVAxyVpy5FaFesEKQ9UXY0AI6gkyF9X8e2Us0tXlVvjaxRim9eWrC0= X-Received: by 2002:a2e:5d57:: with SMTP id r84-v6mr17317891ljb.89.1535988733063; Mon, 03 Sep 2018 08:32:13 -0700 (PDT) MIME-Version: 1.0 References: <20180903151219.tfopetpgyv2rsahg@mutt-hbsd> In-Reply-To: <20180903151219.tfopetpgyv2rsahg@mutt-hbsd> From: zahra rahimkhani Date: Mon, 3 Sep 2018 15:32:08 +0430 Message-ID: Subject: Re: a hardware problem raspberries pi3 model B To: shawn.webb@hardenedbsd.org Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 15:32:15 -0000 Yes, I set them. .It displays output but I cannot type anything. I think it has a hardware problem but I cannot find it. have it other serial or no? best wishes, Zahra On Mon, Sep 3, 2018 at 7:43 PM Shawn Webb wrote: > On Mon, Sep 03, 2018 at 12:42:08PM +0430, zahra rahimkhani wrote: > > Hello friends, > > > > I have a raspberries pi3 model B that have a hardware problem in the > serial > > port and HDMI. > > Could you explain to me How to solve it? > > or is a way that sees the output ? > > What version of FreeBSD are you using? If you're using 12-CURRENT, > then you now need to put in /boot/loader.conf: > > boot_serial="YES" > boot_multicons="YES" > > Thanks, > > -- > Shawn Webb > Cofounder and Security Engineer > HardenedBSD > > Tor-ified Signal: +1 443-546-8752 > Tor+XMPP+OTR: lattera@is.a.hacker.sx > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > From owner-freebsd-arm@freebsd.org Mon Sep 3 17:50:24 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C092FF00B0 for ; Mon, 3 Sep 2018 17:50:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C1E5B8E18A for ; Mon, 3 Sep 2018 17:50:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id E67E82221B for ; Mon, 3 Sep 2018 17:50:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w83HoMre069727 for ; Mon, 3 Sep 2018 17:50:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w83HoM12069726 for freebsd-arm@FreeBSD.org; Mon, 3 Sep 2018 17:50:22 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 231123] make buildworld: c++: error: clang frontend command failed due to signal Date: Mon, 03 Sep 2018 17:50:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: matthias.freitag@tutanota.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 17:50:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231123 Bug ID: 231123 Summary: make buildworld: c++: error: clang frontend command failed due to signal Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: matthias.freitag@tutanota.com Revision: 338426 make buildworld fails with this error: c++ -mlong-calls -O -pipe -I/usr/obj/usr/src/arm.armv6/tmp/obj-tools/lib/clang/libllvm -I/usr/src/contrib/llvm/lib/Target/ARM -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MAC= ROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv6-unknown-freebsd12.0-gnueabihf\" -DLLVM_HOST_TRIPLE=3D\"armv6-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=3D\"/usr/obj/usr/src/arm.armv6/tmp\" -DLLVM_TARGET_ENABLE= _ARM -DLLVM_NATIVE_ASMPARSER=3DLLVMInitializeARMAsmParser -DLLVM_NATIVE_ASMPRINTER=3DLLVMInitializeARMAsmPrinter -DLLVM_NATIVE_DISASSEMBLER=3DLLVMInitializeARMDisassembler -DLLVM_NATIVE_TARGET=3DLLVMInitializeARMTarget -DLLVM_NATIVE_TARGETINFO=3DLLVMInitializeARMTargetInfo -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeARMTargetMC -ffunction-sections -fdata-sections -gline-tables-only -MD -MF.depend.Passes_PassBuilder.o -MTPasses/PassBuilder.o -Qunused-arguments -I/usr/obj/usr/src/arm.armv6/tmp/legacy/usr/include -std=3Dc++11 -fno-exce= ptions -fno-rtti -gline-tables-only -stdlib=3Dlibc++ -Wno-c++11-extensions -c /usr/src/contrib/llvm/lib/Passes/PassBuilder.cpp -o Passes/PassBuilder.o c++: error: unable to execute command: Killed c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0) Target: armv6-unknown-freebsd12.0-gnueabihf Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preproces= sed source, and associated run script. c++: note: diagnostic msg:=20 ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/PassBuilder-ca5dd3.cpp c++: note: diagnostic msg: /tmp/PassBuilder-ca5dd3.sh c++: note: diagnostic msg:=20 ******************** *** Error code 254 Stop. make[4]: stopped in /usr/src/lib/clang/libllvm *** Error code 1 Stop. make[3]: stopped in /usr/src/lib/clang *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Sep 3 18:09:17 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48DA7FF0997 for ; Mon, 3 Sep 2018 18:09:17 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C1CC38EC99; Mon, 3 Sep 2018 18:09:16 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w83I98TM060839 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Sep 2018 11:09:08 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w83I98mH060838; Mon, 3 Sep 2018 11:09:08 -0700 (PDT) (envelope-from jmg) Date: Mon, 3 Sep 2018 11:09:08 -0700 From: John-Mark Gurney To: Ian Lepore Cc: Nicola Mingotti , freebsd-arm Subject: Re: utility for pin in BBB: PX.Y --> pin_mode, pin_name Message-ID: <20180903180908.GG45503@funkthat.com> Mail-Followup-To: Ian Lepore , Nicola Mingotti , freebsd-arm References: <4661fc41-935a-56d5-2cc2-125085daf30a@gmail.com> <1535568374.33841.47.camel@freebsd.org> <1535576856.33841.58.camel@freebsd.org> <1535643488.33841.74.camel@freebsd.org> <1535985010.9486.44.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1535985010.9486.44.camel@freebsd.org> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 03 Sep 2018 11:09:08 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 18:09:17 -0000 Ian Lepore wrote this message on Mon, Sep 03, 2018 at 08:30 -0600: > On Mon, 2018-09-03 at 08:21 +0200, Nicola Mingotti wrote: > > > > On 08/30/18 17:38, Ian Lepore wrote: > > > > > > On Wed, 2018-08-29 at 23:40 +0200, Nicola Mingotti wrote: > > > > > > > > On 08/29/18 23:07, Ian Lepore wrote: > > > > > > > > > > On Wed, 2018-08-29 at 22:26 +0200, Nicola Mingotti wrote: > > > > > > > > > > > > On 08/29/18 20:46, Ian Lepore wrote: > > > > > > > > > > > > > > On Wed, 2018-08-29 at 20:01 +0200, Nicola Mingotti wrote: > > > > > > > > > > > > > > > > Thank you for suggestion Russel, > > > > > > > > > > > > > > > > but unfortunately, at best of my knowldege, > > > > > > > > $> man 3 gpio_open > > > > > > > > and its shell command brother > > > > > > > > $> man 8 gpioctl > > > > > > > > > > > > > > > > are not appropriate, they are useful only if a pin > > > > > > > > has been configured as GPIO pin. > > > > > > > > > > > > > > > > The program i look for would be useful instead to > > > > > > > > esablish > > > > > > > > which physical pin has been configured as GPIO pin or > > > > > > > > PWM, PRU, I2C etc. > > > > > > > > > > > > > > > > I asked also in the Forum, but the only one aswering > > > > > > > > (@Phishry) has given me your same suggestion. > > > > > > > > > > > > > > > > If nobody knows of such a program i will start the > > > > > > > > implementation, > > > > > > > > maybe > > > > > > > > tomorrow. > > > > > > > > > > > > > > > > bye > > > > > > > > Nicola > > > > > > > > > > > > > > > Please bottom-post when replying to freebsd mailing lists. > > > > > > ok ! > > > > > > > > > > > > > > There is no interface defined for getting an fdt_pinctrl > > > > > > > driver > > > > > > > to > > > > > > > return info about the current configuration. Even if such > > > > > > > an > > > > > > > interface > > > > > > > existed, there would also need to be a new driver providing > > > > > > > a > > > > > > > cdev > > > > > > > so > > > > > > > that userland can access the information. > > > > > > ok, no interface. > > > > > > > > > > > > > > There is also nothing in freebsd equivelent to the linux > > > > > > > devmem2 > > > > > > > program. A driver would have to be written to provide > > > > > > > access to > > > > > > > device- > > > > > > > mapped memory before such a program could be written. You > > > > > > > can't > > > > > > > access > > > > > > > arm hardware registers via /dev/mem or /dev/kmem. > > > > > > > > > > > > > > -- Ian > > > > > > I just compiled devmem2 and it seems to work. I did silly > > > > > > modifications. > > > > > > The code is here: http://euriscom.it/data/dm2.c > > > > > > (forget the first comment lines, they are poor, I did not > > > > > > intend > > > > > > to > > > > > > share this, it is my working copy) > > > > > > > > > > > > if i run it: > > > > > > --------------------------------- > > > > > > #> ./dm2 0x44e10998 b > > > > > > /dev/mem opened. > > > > > > Memory mapped at address 0x20221000. > > > > > > Value at address 0x44E10998 (0x20221998): 0x5 > > > > > > --------------------------------- > > > > > > > > > > > > Whic corresponds to what i wrote in the DTO. > > > > > > ----- > > > > > >               pru_pru_pins: pinmux_pru_pru_pins { > > > > > >                          pinctrl-single,pins = < > > > > > >                              // 0x1a4 0x05   /* P9.27 > > > > > > pr1_pru0_pru_r30_5, > > > > > > Mode 5 output pull-down   */ > > > > > >                              0x19c 0x26   /* P9.28 > > > > > > pr1_pru0_pru_r31_3, > > > > > > Mode 6 input pull-down    */ > > > > > >                              0x198 0x05    /* PRU0-2 -- P9.30 > > > > > > -- > > > > > > pr1_pru0_pru_r30_2 ... se in MODE-5  */ > > > > > >                              >; > > > > > >                      }; > > > > > > ----- > > > > > > > > > > > > This is the only test i made but it seems improbable I got > > > > > > the > > > > > > same > > > > > > value by chance;) > > > > > > > > > > > > It goes without saying that I don't understand all what i > > > > > > wrote, > > > > > > so, i could be boldly wrong ;) > > > > > > > > > > > > If it turns out it works let me know, i can make the port. > > > > > > > > > > > > bye > > > > > > n. > > > > > You might accidentally get /dev/mem access to work, but it's > > > > > not by > > > > > design. The rules of the arm memory model forbid mapping the > > > > > same > > > > > physical memory to different virtual addresses using different > > > > > attributes (normal cacheable memory versus Device memory), and > > > > > I > > > > > don't > > > > > see anything in the arm devmem code that handles memory > > > > > attributes. > > > > > > > > > > -- Ian > > > > I would like to discuss more this thing but really, i am too > > > > ignorant > > > > on > > > > this subject. > > > > > > > > What i can say is this, I learnt to use devmem2 from D.Molloy > > > > book > > > > "Exploring BeagleBone", > > > > see pg. 218. The author says this way "bypasses the Linux OS". I > > > > used > > > > the thing > > > > in Linux, it works, as it seems to do in FreeBSD-12-APLHA. > > > > > > > > If can tell you also I remember i used it one day in FreeBSD- > > > > 11.1, > > > > it > > > > was working. > > > > > > > > I don't have the background to go deeper. > > > > > > > > If you can understand why it works and establish that it is > > > > realiable > > > > (even only for reading) let me (us) know ! ;) > > > > > > > > bye > > > > n. > > > > > > > I think it should be possible to do a bit of kernel work to change > > > it > > > from "works by accident" to "does the right thing", except I'm not > > > sure > > > it'll be possible to automatically detect when Device memory is > > > being > > > accessed/mapped. It may be necessary to use the mem(4) ioctls to > > > set > > > the region to MDF_UNCACHEABLE, or even better, define a new > > > MDF_MMIO > > > for mapping ranges of device registers that arm systems have to > > > treat > > > as memory type Device. I'll look into it when I have some time. > > > > > > -- Ian > > Hi, > > > > After a suggestion from @Phisfry on the forum I guess found a way > > to bypass the need of devmem2 to write my "pinfunc" utlity. > > > > I can read (all?) pin configurations from "ofwdump -a -p", indeed I > > see  > > blocks > > like this: > > ---------------------- > > #> ofwdump -a -p > > ---------- > >    Node 0x30f4: pinmux_ehrpwm0_AB_pins > >              phandle: > >                00 00 00 ce > >              pinctrl-single,pins: > >                00 00 01 54 00 00 00 03 00 00 01 50 00 00 00 03 > > ---------- > > > > So I hopefully wrote my script to parse "ofwdump" and what i got is > > this, > > > > -------------------------- > > #> pinfunc.rb > > HEADER   NAME            MODE       FUNCTION > > ... > > P.9.10   SYS_RESETn      1          - > > P.9.11   UART4_RXD       not-found > > P.9.12   GPIO1_28        not-found > > P.9.13   UART4_TXD       not-found > > P.9.14   EHRPWM1A        not-found > > P.9.15   GPIO1_16        not-found > > P.9.16   EHRPWM1B        not-found > > P.9.17   I2C1_SCL        not-found > > P.9.18   I2C1_SDA        not-found > > P.9.19   I2C2_SCL        3          I2C2_SCL > > P.9.20   I2C2_SDA        3          I2C2_SDA > > P.9.21   UART2_TXD       3          ehrpwm0B > > P.9.22   UART2_RXD       3          ehrpwm0A > > P.9.23   GPIO1_17        not-found > > P.9.24   UART1_TXD       not-found > > P.9.25   GPIO3_21        0          mcasp0_ahclkx > > P.9.26   UART1_RXD       not-found > > P.9.27   GPIO3_19        not-found > > P.9.28   SPI1_CS0        6          pr1_pru0_pru_r31_3 > > P.9.29   SPI1_D0         0          mcasp0_fsx > > P.9.30   SPI1_D1         6          pr1_pru0_pru_r31_2 > > P.9.31   SPI1_SCLK       0          mcasp0_aclkx > > P.9.32   VADC > > ... > > --------------------------- > > > > The only isssue seems to be that GPIO pins do not appear. > > I could fix the problem parsing the output of "gpioctl -f /dev/gpioX/ > > -l" > > > > But I have a couple of questions : > > 1] Is there somewhare written the GPIO pins configuration in > > "ofwdump" ? > > 2] If it is not written there, what is the reason ? > > 2.1] Where is the boot GPIO pins configuration written ? > > 2.2] I looked also in "dtc -I dtb -O dts /boot/dtb/am335x- > > boneblack.dtb  > > > > > > less" > > but at the best of my ability to read it I could not find the GPIOs  > > configuration. > > > > bye > > nico > > The pinctrl info in the fdt data is used to override pins from their > default settings that the chip powers on with. So you have to start > with empirical knowledge of that, and treat the fdt data as a set of > modifications to it. Obviously the pin defaults are different for every > soc. > > In theory, the pinctrl data is not static, it can be changed at > runtime. In practice, that rarely happens, and could only happen if the > node has multiple pinctrl-N properties so that the drivers can switch > between them. > > Rather than parsing the ascii output from ofwdump (a program that's > hard to love in any way), you'd probably be better off reading the > actual binary data (sysctl -b hw.fdt.dtb | yourprog), and parse it > using libfdt. Hmm, do we distribute libfdt? I think not. It should at > least be a port even if it's not licensed properly to be distributed > with the base system. This should work: sysctl -b hw.fdt.dtb | dtc -I dtb -O dts -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Mon Sep 3 18:16:38 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFAB7FF0D76 for ; Mon, 3 Sep 2018 18:16:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 813008F12B for ; Mon, 3 Sep 2018 18:16:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22c.google.com with SMTP id j198-v6so11876485ita.0 for ; Mon, 03 Sep 2018 11:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0WzfTYg3yAOAOOCxqs97D1+MJ66p06HmDlOITSyP3AE=; b=ItEjqj8IfnLb7miso/r6l4nRcM+Kjfyse6OkBpj6jJDBqUiSV21cSEO6SBX7h8MGr8 JnpsvHHeWOiajQ7Bseyjmg3iNKtSOdUK3Suv8rkpbmkJ+B80+aFCVL81nmSyxLi7S699 +KUgAVEDzs+ssBVnWRfO4pUAV/zpnM54lFHocVF44mIfiN5RHTTV8W4aE7tSERbzl+r7 fy+IDmz2sXzmA5dlNqOTrR5UX5rZTJ+JAToSNe7lhwO5oVJuhknGvLy4Ikz40lxTrNDf /cs2sfNetQjGu0kMkTw4ibHwMKq4g0wYkxYXhSBMZl+s3QhyBBzsCp+R0bFRxxxMEbnJ TksQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0WzfTYg3yAOAOOCxqs97D1+MJ66p06HmDlOITSyP3AE=; b=P+YqB2hD+Uk2ZOrSSuAUO1h5SgIqW0eaPQDJDh7yl0bqc1ilCSMFgbQEhBvbi59gZa ftKyoPwO/a0HDB3lb9I/s78tn7IJITLe1aUn2IfejGImLU04zWlmsuAatIu5gb5MV7n5 ld+aH0fpm01iCxw6PQv95Ywvim2su72Fgt3Lb0XT4YrVs6uDOgrJwzc+/vXhn9+S93Fw zwzhh7GxIRr3Orf24DxPqejTpDpf4CldIJ3HwjcLvuL4MNswVn6/FHaamg9OsZeDTVuZ tu/e1LuakKC+sBwpmN7+jNllptGYVxSdFtky6jZWtL5KBVijGMpYofG3rw2CHhhxBlrg Acqg== X-Gm-Message-State: APzg51DrLhoZsA35/Yk5ahAe1vFAmyl6GSoaB3a0g75XpeKruVJ4Ngrt b9QA1OhovKw1y2LbZfnUkHec13g+xH5Fucx88tkKig== X-Google-Smtp-Source: ANB0VdajGc5mROkIZVLKP/Aw2O1RE+8KSlPYq10ncxz1YTnCEwH8KHMzlZzrsOvjTKt+nPzSHh4J5tg8YR33a3OgCTs= X-Received: by 2002:a02:59cc:: with SMTP id v73-v6mr20917598jad.5.1535998596534; Mon, 03 Sep 2018 11:16:36 -0700 (PDT) MIME-Version: 1.0 References: <4661fc41-935a-56d5-2cc2-125085daf30a@gmail.com> <1535568374.33841.47.camel@freebsd.org> <1535576856.33841.58.camel@freebsd.org> <1535643488.33841.74.camel@freebsd.org> <1535985010.9486.44.camel@freebsd.org> <20180903180908.GG45503@funkthat.com> In-Reply-To: <20180903180908.GG45503@funkthat.com> From: Warner Losh Date: Mon, 3 Sep 2018 12:16:24 -0600 Message-ID: Subject: Re: utility for pin in BBB: PX.Y --> pin_mode, pin_name To: Ian Lepore , Nicola Mingotti , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 18:16:38 -0000 On Mon, Sep 3, 2018 at 12:10 PM John-Mark Gurney wrote: > Ian Lepore wrote this message on Mon, Sep 03, 2018 at 08:30 -0600: > > On Mon, 2018-09-03 at 08:21 +0200, Nicola Mingotti wrote: > > > > > > On 08/30/18 17:38, Ian Lepore wrote: > > > > > > > > On Wed, 2018-08-29 at 23:40 +0200, Nicola Mingotti wrote: > > > > > > > > > > On 08/29/18 23:07, Ian Lepore wrote: > > > > > > > > > > > > On Wed, 2018-08-29 at 22:26 +0200, Nicola Mingotti wrote: > > > > > > > > > > > > > > On 08/29/18 20:46, Ian Lepore wrote: > > > > > > > > > > > > > > > > On Wed, 2018-08-29 at 20:01 +0200, Nicola Mingotti wrote: > > > > > > > > > > > > > > > > > > Thank you for suggestion Russel, > > > > > > > > > > > > > > > > > > but unfortunately, at best of my knowldege, > > > > > > > > > $> man 3 gpio_open > > > > > > > > > and its shell command brother > > > > > > > > > $> man 8 gpioctl > > > > > > > > > > > > > > > > > > are not appropriate, they are useful only if a pin > > > > > > > > > has been configured as GPIO pin. > > > > > > > > > > > > > > > > > > The program i look for would be useful instead to > > > > > > > > > esablish > > > > > > > > > which physical pin has been configured as GPIO pin or > > > > > > > > > PWM, PRU, I2C etc. > > > > > > > > > > > > > > > > > > I asked also in the Forum, but the only one aswering > > > > > > > > > (@Phishry) has given me your same suggestion. > > > > > > > > > > > > > > > > > > If nobody knows of such a program i will start the > > > > > > > > > implementation, > > > > > > > > > maybe > > > > > > > > > tomorrow. > > > > > > > > > > > > > > > > > > bye > > > > > > > > > Nicola > > > > > > > > > > > > > > > > > Please bottom-post when replying to freebsd mailing lists. > > > > > > > ok ! > > > > > > > > > > > > > > > > There is no interface defined for getting an fdt_pinctrl > > > > > > > > driver > > > > > > > > to > > > > > > > > return info about the current configuration. Even if such > > > > > > > > an > > > > > > > > interface > > > > > > > > existed, there would also need to be a new driver providing > > > > > > > > a > > > > > > > > cdev > > > > > > > > so > > > > > > > > that userland can access the information. > > > > > > > ok, no interface. > > > > > > > > > > > > > > > > There is also nothing in freebsd equivelent to the linux > > > > > > > > devmem2 > > > > > > > > program. A driver would have to be written to provide > > > > > > > > access to > > > > > > > > device- > > > > > > > > mapped memory before such a program could be written. You > > > > > > > > can't > > > > > > > > access > > > > > > > > arm hardware registers via /dev/mem or /dev/kmem. > > > > > > > > > > > > > > > > -- Ian > > > > > > > I just compiled devmem2 and it seems to work. I did silly > > > > > > > modifications. > > > > > > > The code is here: http://euriscom.it/data/dm2.c > > > > > > > (forget the first comment lines, they are poor, I did not > > > > > > > intend > > > > > > > to > > > > > > > share this, it is my working copy) > > > > > > > > > > > > > > if i run it: > > > > > > > --------------------------------- > > > > > > > #> ./dm2 0x44e10998 b > > > > > > > /dev/mem opened. > > > > > > > Memory mapped at address 0x20221000. > > > > > > > Value at address 0x44E10998 (0x20221998): 0x5 > > > > > > > --------------------------------- > > > > > > > > > > > > > > Whic corresponds to what i wrote in the DTO. > > > > > > > ----- > > > > > > > pru_pru_pins: pinmux_pru_pru_pins { > > > > > > > pinctrl-single,pins = < > > > > > > > // 0x1a4 0x05 /* P9.27 > > > > > > > pr1_pru0_pru_r30_5, > > > > > > > Mode 5 output pull-down */ > > > > > > > 0x19c 0x26 /* P9.28 > > > > > > > pr1_pru0_pru_r31_3, > > > > > > > Mode 6 input pull-down */ > > > > > > > 0x198 0x05 /* PRU0-2 -- P9.30 > > > > > > > -- > > > > > > > pr1_pru0_pru_r30_2 ... se in MODE-5 */ > > > > > > > >; > > > > > > > }; > > > > > > > ----- > > > > > > > > > > > > > > This is the only test i made but it seems improbable I got > > > > > > > the > > > > > > > same > > > > > > > value by chance;) > > > > > > > > > > > > > > It goes without saying that I don't understand all what i > > > > > > > wrote, > > > > > > > so, i could be boldly wrong ;) > > > > > > > > > > > > > > If it turns out it works let me know, i can make the port. > > > > > > > > > > > > > > bye > > > > > > > n. > > > > > > You might accidentally get /dev/mem access to work, but it's > > > > > > not by > > > > > > design. The rules of the arm memory model forbid mapping the > > > > > > same > > > > > > physical memory to different virtual addresses using different > > > > > > attributes (normal cacheable memory versus Device memory), and > > > > > > I > > > > > > don't > > > > > > see anything in the arm devmem code that handles memory > > > > > > attributes. > > > > > > > > > > > > -- Ian > > > > > I would like to discuss more this thing but really, i am too > > > > > ignorant > > > > > on > > > > > this subject. > > > > > > > > > > What i can say is this, I learnt to use devmem2 from D.Molloy > > > > > book > > > > > "Exploring BeagleBone", > > > > > see pg. 218. The author says this way "bypasses the Linux OS". I > > > > > used > > > > > the thing > > > > > in Linux, it works, as it seems to do in FreeBSD-12-APLHA. > > > > > > > > > > If can tell you also I remember i used it one day in FreeBSD- > > > > > 11.1, > > > > > it > > > > > was working. > > > > > > > > > > I don't have the background to go deeper. > > > > > > > > > > If you can understand why it works and establish that it is > > > > > realiable > > > > > (even only for reading) let me (us) know ! ;) > > > > > > > > > > bye > > > > > n. > > > > > > > > > I think it should be possible to do a bit of kernel work to change > > > > it > > > > from "works by accident" to "does the right thing", except I'm not > > > > sure > > > > it'll be possible to automatically detect when Device memory is > > > > being > > > > accessed/mapped. It may be necessary to use the mem(4) ioctls to > > > > set > > > > the region to MDF_UNCACHEABLE, or even better, define a new > > > > MDF_MMIO > > > > for mapping ranges of device registers that arm systems have to > > > > treat > > > > as memory type Device. I'll look into it when I have some time. > > > > > > > > -- Ian > > > Hi, > > > > > > After a suggestion from @Phisfry on the forum I guess found a way > > > to bypass the need of devmem2 to write my "pinfunc" utlity. > > > > > > I can read (all?) pin configurations from "ofwdump -a -p", indeed I > > > see > > > blocks > > > like this: > > > ---------------------- > > > #> ofwdump -a -p > > > ---------- > > > Node 0x30f4: pinmux_ehrpwm0_AB_pins > > > phandle: > > > 00 00 00 ce > > > pinctrl-single,pins: > > > 00 00 01 54 00 00 00 03 00 00 01 50 00 00 00 03 > > > ---------- > > > > > > So I hopefully wrote my script to parse "ofwdump" and what i got is > > > this, > > > > > > -------------------------- > > > #> pinfunc.rb > > > HEADER NAME MODE FUNCTION > > > ... > > > P.9.10 SYS_RESETn 1 - > > > P.9.11 UART4_RXD not-found > > > P.9.12 GPIO1_28 not-found > > > P.9.13 UART4_TXD not-found > > > P.9.14 EHRPWM1A not-found > > > P.9.15 GPIO1_16 not-found > > > P.9.16 EHRPWM1B not-found > > > P.9.17 I2C1_SCL not-found > > > P.9.18 I2C1_SDA not-found > > > P.9.19 I2C2_SCL 3 I2C2_SCL > > > P.9.20 I2C2_SDA 3 I2C2_SDA > > > P.9.21 UART2_TXD 3 ehrpwm0B > > > P.9.22 UART2_RXD 3 ehrpwm0A > > > P.9.23 GPIO1_17 not-found > > > P.9.24 UART1_TXD not-found > > > P.9.25 GPIO3_21 0 mcasp0_ahclkx > > > P.9.26 UART1_RXD not-found > > > P.9.27 GPIO3_19 not-found > > > P.9.28 SPI1_CS0 6 pr1_pru0_pru_r31_3 > > > P.9.29 SPI1_D0 0 mcasp0_fsx > > > P.9.30 SPI1_D1 6 pr1_pru0_pru_r31_2 > > > P.9.31 SPI1_SCLK 0 mcasp0_aclkx > > > P.9.32 VADC > > > ... > > > --------------------------- > > > > > > The only isssue seems to be that GPIO pins do not appear. > > > I could fix the problem parsing the output of "gpioctl -f /dev/gpioX/ > > > -l" > > > > > > But I have a couple of questions : > > > 1] Is there somewhare written the GPIO pins configuration in > > > "ofwdump" ? > > > 2] If it is not written there, what is the reason ? > > > 2.1] Where is the boot GPIO pins configuration written ? > > > 2.2] I looked also in "dtc -I dtb -O dts /boot/dtb/am335x- > > > boneblack.dtb > > > > > > > > less" > > > but at the best of my ability to read it I could not find the GPIOs > > > configuration. > > > > > > bye > > > nico > > > > The pinctrl info in the fdt data is used to override pins from their > > default settings that the chip powers on with. So you have to start > > with empirical knowledge of that, and treat the fdt data as a set of > > modifications to it. Obviously the pin defaults are different for every > > soc. > > > > In theory, the pinctrl data is not static, it can be changed at > > runtime. In practice, that rarely happens, and could only happen if the > > node has multiple pinctrl-N properties so that the drivers can switch > > between them. > > > > Rather than parsing the ascii output from ofwdump (a program that's > > hard to love in any way), you'd probably be better off reading the > > actual binary data (sysctl -b hw.fdt.dtb | yourprog), and parse it > > using libfdt. Hmm, do we distribute libfdt? I think not. It should at > > least be a port even if it's not licensed properly to be distributed > > with the base system. > > This should work: > sysctl -b hw.fdt.dtb | dtc -I dtb -O dts > It would, but then you'd be left parsing the output. And to know what's actually going on, you have to look at a bunch of nodes. It's a lot easier to thread that with libfdt than it is to roll your own code to do it. Warner From owner-freebsd-arm@freebsd.org Mon Sep 3 20:12:00 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D9A3FF4E44 for ; Mon, 3 Sep 2018 20:12:00 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C0FF74D1F; Mon, 3 Sep 2018 20:11:56 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: by mail-wm0-x22e.google.com with SMTP id s12-v6so2230401wmc.0; Mon, 03 Sep 2018 13:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=pD/wUg7WxQKcDZVyRamGKJgi11boJH9tfqPDZEe34jA=; b=MFKxdafZmuXIXRlA/m843PaXXE9e2yBrmWgbN/QZY5COTMqRF2TibLqY4FaAY35ZIB Iu0vJ9eIwu0XxyPAlzLGpA3HE/u3kDVjqFKBNlw4Z/nqpQJ2OndOfF1//JS3s2cOTpx3 0OBmIaHntGD2qrlI/BT9wsjCsEWucUJnksd3OZse+3voG/hBb7FDQWNqzNqykXu+gShB XW4O9Kr80ZnvHrO9zoyLF90u4SjDKO04kFIbmkydBloU1CNxPGSy5mzWZmwcSVMNFdk4 f7X0O1sKRufr9yWJ4rnx8whVKE9lacCYRbn6aLryUa1KZRtgnEnoSzUycSr8mvmwTRQc B1OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=pD/wUg7WxQKcDZVyRamGKJgi11boJH9tfqPDZEe34jA=; b=qqdFdIfX1KNHuEuyutcPCPS94DE8wgQsxmqw3SZWfJqHEU5a+Fr1F4dJ/FWB/iKUeL nR04ztnsrWCgWeWXZCdHsOu6pihnYSFqa/UuQq140uus5FcnRSPPaKBkrkeAG2kq7RGn vnrg8DdnTM2Iq3vPvwboCEx37bUTfnCSlSkEtsliSx2SKHOdTQxfX3kxgl3NOKjc/jae YF1Pbnls3RTVHjDs3QYjowLcD8Cbt83l7Eg8vmdxWcSsqjQnBIB85L3sMV43AUsAi4rW +vV8DkOt40/1c34qHxvCEmzFG+L6mHjFVv0x2fF5jI+9Pb9pVULFdIFcTICG0mlYB1/J 2RsA== X-Gm-Message-State: APzg51CBjoC+Gg0Nnd/qW3PLa9F4/K8iLN6sylNkDOxVoGbSDycUOdW+ fs74Ne++omXEznR8De+S46qTTLuD X-Google-Smtp-Source: ANB0VdZFLGknqPUXyXi3PqH2RRtu011EubHQsqNLhMvlTdgNBBGJxb8rvVIpdX3Y+IHiLjn873UTMA== X-Received: by 2002:a1c:80d8:: with SMTP id b207-v6mr580432wmd.146.1536005514550; Mon, 03 Sep 2018 13:11:54 -0700 (PDT) Received: from [172.16.0.150] (net-188-219-105-237.cust.vodafonedsl.it. [188.219.105.237]) by smtp.gmail.com with ESMTPSA id q5-v6sm24605928wmd.29.2018.09.03.13.11.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 13:11:53 -0700 (PDT) Subject: Re: utility for pin in BBB: PX.Y --> pin_mode, pin_name To: Warner Losh , Ian Lepore , "freebsd-arm@freebsd.org" References: <4661fc41-935a-56d5-2cc2-125085daf30a@gmail.com> <1535568374.33841.47.camel@freebsd.org> <1535576856.33841.58.camel@freebsd.org> <1535643488.33841.74.camel@freebsd.org> <1535985010.9486.44.camel@freebsd.org> <20180903180908.GG45503@funkthat.com> From: Nicola Mingotti Message-ID: Date: Mon, 3 Sep 2018 22:11:51 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 20:12:00 -0000 On 09/03/18 20:16, Warner Losh wrote: > > > On Mon, Sep 3, 2018 at 12:10 PM John-Mark Gurney > wrote: > > Ian Lepore wrote this message on Mon, Sep 03, 2018 at 08:30 -0600: > > On Mon, 2018-09-03 at 08:21 +0200, Nicola Mingotti wrote: > > > > > > On 08/30/18 17:38, Ian Lepore wrote: > > > > > > > > On Wed, 2018-08-29 at 23:40 +0200, Nicola Mingotti wrote: > > > > > > > > > > On 08/29/18 23:07, Ian Lepore wrote: > > > > > > > > > > > > On Wed, 2018-08-29 at 22:26 +0200, Nicola Mingotti wrote: > > > > > > > > > > > > > > On 08/29/18 20:46, Ian Lepore wrote: > > > > > > > > > > > > > > > > On Wed, 2018-08-29 at 20:01 +0200, Nicola Mingotti > wrote: > > > > > > > > > > > > > > > > > > Thank you for suggestion Russel, > > > > > > > > > > > > > > > > > > but unfortunately, at best of my knowldege, > > > > > > > > > $> man 3 gpio_open > > > > > > > > > and its shell command brother > > > > > > > > > $> man 8 gpioctl > > > > > > > > > > > > > > > > > > are not appropriate, they are useful only if a pin > > > > > > > > > has been configured as GPIO pin. > > > > > > > > > > > > > > > > > > The program i look for would be useful instead to > > > > > > > > > esablish > > > > > > > > > which physical pin has been configured as GPIO pin or > > > > > > > > > PWM, PRU, I2C etc. > > > > > > > > > > > > > > > > > > I asked also in the Forum, but the only one aswering > > > > > > > > > (@Phishry) has given me your same suggestion. > > > > > > > > > > > > > > > > > > If nobody knows of such a program i will start the > > > > > > > > > implementation, > > > > > > > > > maybe > > > > > > > > > tomorrow. > > > > > > > > > > > > > > > > > > bye > > > > > > > > > Nicola > > > > > > > > > > > > > > > > > Please bottom-post when replying to freebsd mailing > lists. > > > > > > > ok ! > > > > > > > > > > > > > > > > There is no interface defined for getting an fdt_pinctrl > > > > > > > > driver > > > > > > > > to > > > > > > > > return info about the current configuration. Even if > such > > > > > > > > an > > > > > > > > interface > > > > > > > > existed, there would also need to be a new driver > providing > > > > > > > > a > > > > > > > > cdev > > > > > > > > so > > > > > > > > that userland can access the information. > > > > > > > ok, no interface. > > > > > > > > > > > > > > > > There is also nothing in freebsd equivelent to the linux > > > > > > > > devmem2 > > > > > > > > program. A driver would have to be written to provide > > > > > > > > access to > > > > > > > > device- > > > > > > > > mapped memory before such a program could be > written. You > > > > > > > > can't > > > > > > > > access > > > > > > > > arm hardware registers via /dev/mem or /dev/kmem. > > > > > > > > > > > > > > > > -- Ian > > > > > > > I just compiled devmem2 and it seems to work. I did silly > > > > > > > modifications. > > > > > > > The code is here: http://euriscom.it/data/dm2.c > > > > > > > (forget the first comment lines, they are poor, I did not > > > > > > > intend > > > > > > > to > > > > > > > share this, it is my working copy) > > > > > > > > > > > > > > if i run it: > > > > > > > --------------------------------- > > > > > > > #> ./dm2 0x44e10998 b > > > > > > > /dev/mem opened. > > > > > > > Memory mapped at address 0x20221000. > > > > > > > Value at address 0x44E10998 (0x20221998): 0x5 > > > > > > > --------------------------------- > > > > > > > > > > > > > > Whic corresponds to what i wrote in the DTO. > > > > > > > ----- > > > > > > >               pru_pru_pins: pinmux_pru_pru_pins { > > > > > > > pinctrl-single,pins = < > > > > > > > // 0x1a4 0x05   /* P9.27 > > > > > > > pr1_pru0_pru_r30_5, > > > > > > > Mode 5 output pull-down   */ > > > > > > > 0x19c 0x26   /* P9.28 > > > > > > > pr1_pru0_pru_r31_3, > > > > > > > Mode 6 input pull-down    */ > > > > > > > 0x198 0x05    /* PRU0-2 -- P9.30 > > > > > > > -- > > > > > > > pr1_pru0_pru_r30_2 ... se in MODE-5  */ > > > > > > > >; > > > > > > >                      }; > > > > > > > ----- > > > > > > > > > > > > > > This is the only test i made but it seems improbable I got > > > > > > > the > > > > > > > same > > > > > > > value by chance;) > > > > > > > > > > > > > > It goes without saying that I don't understand all what i > > > > > > > wrote, > > > > > > > so, i could be boldly wrong ;) > > > > > > > > > > > > > > If it turns out it works let me know, i can make the port. > > > > > > > > > > > > > > bye > > > > > > > n. > > > > > > You might accidentally get /dev/mem access to work, but it's > > > > > > not by > > > > > > design. The rules of the arm memory model forbid mapping the > > > > > > same > > > > > > physical memory to different virtual addresses using > different > > > > > > attributes (normal cacheable memory versus Device > memory), and > > > > > > I > > > > > > don't > > > > > > see anything in the arm devmem code that handles memory > > > > > > attributes. > > > > > > > > > > > > -- Ian > > > > > I would like to discuss more this thing but really, i am too > > > > > ignorant > > > > > on > > > > > this subject. > > > > > > > > > > What i can say is this, I learnt to use devmem2 from D.Molloy > > > > > book > > > > > "Exploring BeagleBone", > > > > > see pg. 218. The author says this way "bypasses the Linux > OS". I > > > > > used > > > > > the thing > > > > > in Linux, it works, as it seems to do in FreeBSD-12-APLHA. > > > > > > > > > > If can tell you also I remember i used it one day in FreeBSD- > > > > > 11.1, > > > > > it > > > > > was working. > > > > > > > > > > I don't have the background to go deeper. > > > > > > > > > > If you can understand why it works and establish that it is > > > > > realiable > > > > > (even only for reading) let me (us) know ! ;) > > > > > > > > > > bye > > > > > n. > > > > > > > > > I think it should be possible to do a bit of kernel work to > change > > > > it > > > > from "works by accident" to "does the right thing", except > I'm not > > > > sure > > > > it'll be possible to automatically detect when Device memory is > > > > being > > > > accessed/mapped. It may be necessary to use the mem(4) ioctls to > > > > set > > > > the region to MDF_UNCACHEABLE, or even better, define a new > > > > MDF_MMIO > > > > for mapping ranges of device registers that arm systems have to > > > > treat > > > > as memory type Device. I'll look into it when I have some time. > > > > > > > > -- Ian > > > Hi, > > > > > > After a suggestion from @Phisfry on the forum I guess found a way > > > to bypass the need of devmem2 to write my "pinfunc" utlity. > > > > > > I can read (all?) pin configurations from "ofwdump -a -p", > indeed I > > > see > > > blocks > > > like this: > > > ---------------------- > > > #> ofwdump -a -p > > > ---------- > > >    Node 0x30f4: pinmux_ehrpwm0_AB_pins > > >              phandle: > > >                00 00 00 ce > > >              pinctrl-single,pins: > > >                00 00 01 54 00 00 00 03 00 00 01 50 00 00 00 03 > > > ---------- > > > > > > So I hopefully wrote my script to parse "ofwdump" and what i > got is > > > this, > > > > > > -------------------------- > > > #> pinfunc.rb > > > HEADER   NAME            MODE       FUNCTION > > > ... > > > P.9.10   SYS_RESETn      1          - > > > P.9.11   UART4_RXD       not-found > > > P.9.12   GPIO1_28        not-found > > > P.9.13   UART4_TXD       not-found > > > P.9.14   EHRPWM1A        not-found > > > P.9.15   GPIO1_16        not-found > > > P.9.16   EHRPWM1B        not-found > > > P.9.17   I2C1_SCL        not-found > > > P.9.18   I2C1_SDA        not-found > > > P.9.19   I2C2_SCL        3          I2C2_SCL > > > P.9.20   I2C2_SDA        3          I2C2_SDA > > > P.9.21   UART2_TXD       3          ehrpwm0B > > > P.9.22   UART2_RXD       3          ehrpwm0A > > > P.9.23   GPIO1_17        not-found > > > P.9.24   UART1_TXD       not-found > > > P.9.25   GPIO3_21        0          mcasp0_ahclkx > > > P.9.26   UART1_RXD       not-found > > > P.9.27   GPIO3_19        not-found > > > P.9.28   SPI1_CS0        6 pr1_pru0_pru_r31_3 > > > P.9.29   SPI1_D0         0          mcasp0_fsx > > > P.9.30   SPI1_D1         6 pr1_pru0_pru_r31_2 > > > P.9.31   SPI1_SCLK       0          mcasp0_aclkx > > > P.9.32   VADC > > > ... > > > --------------------------- > > > > > > The only isssue seems to be that GPIO pins do not appear. > > > I could fix the problem parsing the output of "gpioctl -f > /dev/gpioX/ > > > -l" > > > > > > But I have a couple of questions : > > > 1] Is there somewhare written the GPIO pins configuration in > > > "ofwdump" ? > > > 2] If it is not written there, what is the reason ? > > > 2.1] Where is the boot GPIO pins configuration written ? > > > 2.2] I looked also in "dtc -I dtb -O dts /boot/dtb/am335x- > > > boneblack.dtb > > > > > > > > less" > > > but at the best of my ability to read it I could not find the > GPIOs > > > configuration. > > > > > > bye > > > nico > > > > The pinctrl info in the fdt data is used to override pins from their > > default settings that the chip powers on with. So you have to start > > with empirical knowledge of that, and treat the fdt data as a set of > > modifications to it. Obviously the pin defaults are different > for every > > soc. > > > > In theory, the pinctrl data is not static, it can be changed at > > runtime. In practice, that rarely happens, and could only happen > if the > > node has multiple pinctrl-N properties so that the drivers can > switch > > between them. > > > > Rather than parsing the ascii output from ofwdump (a program that's > > hard to love in any way), you'd probably be better off reading the > > actual binary data (sysctl -b hw.fdt.dtb | yourprog), and parse it > > using libfdt. Hmm, do we distribute libfdt? I think not. It > should at > > least be a port even if it's not licensed properly to be distributed > > with the base system. > > This should work: > sysctl -b hw.fdt.dtb | dtc -I dtb -O dts > > > It would, but then you'd be left parsing the output. And to know > what's actually going on, you have to look at a bunch of nodes. It's a > lot easier to thread that with libfdt than it is to roll your own code > to do it. > > Warner Thank you all for your comments and suggestions, these are the opinion I maturated. 1] parsing "sysctl -b hw.fdt.dtb | dtc -I dtb -O dts" is a bit easier than parsing |"ofwdump -a -p" anyhow, as far as i could esablish, all the interesting parts are, in both cases, just after "pinctrl-single,pins:" string. I already parsed and "deciphered" those blocks, no problem. 2] The problem for me remains only for gpio pins. From Ian answer I see they come configured by defualt on the chip. That is why they are not in the DTB. 3] libft. could be interesting to bypass the parsing, but since it is not in a port I guess I understand I shoud compile the base-system to have it. => 3 problems arise: first, I never compiled the base-system since now;) second, it would be not much practical to recompile the base for each machine in which I want to use my utility and last, other people could not use it without compiling base. In conclusion i will do as follow: I will finish my utility parsing text repr. of the DTB and using "gpioctl" + and maps like this one: https://vadl.github.io/images/bbb/P8Header.png I will give you the script link when it is finished. In a second moment I can rewrite it in C, for now, with all the parsing stuff, it is far better to start with a scripting language Ruby. bye nico | -- -------------------------- Dr. Nicola Mingotti R&D - Borghi Srl CTO - BondInsider -------------------------- From owner-freebsd-arm@freebsd.org Mon Sep 3 20:24:16 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F9BDFF55C3 for ; Mon, 3 Sep 2018 20:24:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 108807553A for ; Mon, 3 Sep 2018 20:24:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 596E9238CC for ; Mon, 3 Sep 2018 20:24:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w83KOFME007306 for ; Mon, 3 Sep 2018 20:24:15 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w83KOF32007305 for freebsd-arm@FreeBSD.org; Mon, 3 Sep 2018 20:24:15 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 231123] make buildworld: c++: error: clang frontend command failed due to signal Date: Mon, 03 Sep 2018 20:24:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: matthias.freitag@tutanota.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 20:24:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231123 matthias.freitag@tutanota.com changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|New |Closed --- Comment #4 from matthias.freitag@tutanota.com --- *** This bug has been marked as a duplicate of bug 227609 *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Sep 3 22:52:48 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEF48FF8D11 for ; Mon, 3 Sep 2018 22:52:47 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 101A37A0A0; Mon, 3 Sep 2018 22:52:47 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: by mail-wr1-x42c.google.com with SMTP id g33-v6so2005659wrd.1; Mon, 03 Sep 2018 15:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=x13/PAIoQdjXUnz0tmQi78kbwEuBMDNbPmOc6C2hJ+A=; b=R87UfRBXXpIua3cZVwJlaiJaaWl7miJriIrl7ofx3aVnHsAzhLtshD/TOtFJy9P+P/ ucPG3AgEzPvUIWmi+qS3k0x5qB2m8yxFdEBRSlApVkvH0H542Lmt47DbZPlZY+nZZZd7 vvlefHfP0cXuE0MoFHkffMedXo307aAYIJxT1P2Wh7aDQ9FgcUSYtxY7rFi9scx1qoJr dW3l1EOPI6fTelDBq6AK8+GP8MSwOWlpNGtFcUQL2vVCN9pQZVTV/x2uiA5uQDgScjma 4UUYQDAlPTv2X4GbT3+MqT/rCHQxPRBkyXmXIDY8mZDBbga7CoGGXqIZQefT8jYhXbpE Jhqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=x13/PAIoQdjXUnz0tmQi78kbwEuBMDNbPmOc6C2hJ+A=; b=OADVl20gxoJJl1/ETdr3mx4yTUYCbxm1LKSQ0pOWhLq0PGJiPjIvBekovGncJqXbnv pBvR7aRRADhRp+RddOOAYx253/0MyJIWgK51hH4XnHgwhbTBMdcclKMM4PZtx+mKmbb6 c5dC0Rl0B5l3D48iPwEX1fIbxufypvzQOVN/JTyPcfKEUK/tj0DvIFu/ExRCHPTZy5Fr 1L6m8SXISiAbMBCx5d579UsVFIN/6oA0qWd7jZW3UOqxwn8VJlpBDrcoxRBHvzxTepzc uxc8EqOg5TvoZLIxjKK9a6w+fE0ZVYHFHX4eLNUdGx3/+hV9ul3C91q8WqJvfmLnTn/H wmKA== X-Gm-Message-State: APzg51Cw0M/n/RRKqEWywksaHTTtcS71W68RFEKKKt6jTMcVOO13bxvH wG92488o77KOT8t6kNjpqg4= X-Google-Smtp-Source: ANB0VdZ4pmY+HusTIgq0pOEsJHtw7iJg7yQh4wuGQVkI2EDdKuVQ+CcvYqP7nLvY9rVbFIjV0tDT8w== X-Received: by 2002:adf:80ea:: with SMTP id 97-v6mr19965851wrl.57.1536015164675; Mon, 03 Sep 2018 15:52:44 -0700 (PDT) Received: from [172.16.0.150] (net-188-219-105-237.cust.vodafonedsl.it. [188.219.105.237]) by smtp.gmail.com with ESMTPSA id q21-v6sm14211861wmq.3.2018.09.03.15.52.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 15:52:43 -0700 (PDT) Subject: Re: utility for pin in BBB: PX.Y --> pin_mode, pin_name To: Warner Losh , Ian Lepore , "freebsd-arm@freebsd.org" References: <4661fc41-935a-56d5-2cc2-125085daf30a@gmail.com> <1535568374.33841.47.camel@freebsd.org> <1535576856.33841.58.camel@freebsd.org> <1535643488.33841.74.camel@freebsd.org> <1535985010.9486.44.camel@freebsd.org> <20180903180908.GG45503@funkthat.com> From: Nicola Mingotti Message-ID: <34764b1b-42b4-d9c8-8c6b-4195335805dc@gmail.com> Date: Tue, 4 Sep 2018 00:52:41 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 22:52:48 -0000 On 09/03/18 20:16, Warner Losh wrote: > > > On Mon, Sep 3, 2018 at 12:10 PM John-Mark Gurney > wrote: > > Ian Lepore wrote this message on Mon, Sep 03, 2018 at 08:30 -0600: > > On Mon, 2018-09-03 at 08:21 +0200, Nicola Mingotti wrote: > > > > > > On 08/30/18 17:38, Ian Lepore wrote: > > > > > > > > On Wed, 2018-08-29 at 23:40 +0200, Nicola Mingotti wrote: > > > > > > > > > > On 08/29/18 23:07, Ian Lepore wrote: > > > > > > > > > > > > On Wed, 2018-08-29 at 22:26 +0200, Nicola Mingotti wrote: > > > > > > > > > > > > > > On 08/29/18 20:46, Ian Lepore wrote: > > > > > > > > > > > > > > > > On Wed, 2018-08-29 at 20:01 +0200, Nicola Mingotti > wrote: > > > > > > > > > > > > > > > > > > Thank you for suggestion Russel, > > > > > > > > > > > > > > > > > > but unfortunately, at best of my knowldege, > > > > > > > > > $> man 3 gpio_open > > > > > > > > > and its shell command brother > > > > > > > > > $> man 8 gpioctl > > > > > > > > > > > > > > > > > > are not appropriate, they are useful only if a pin > > > > > > > > > has been configured as GPIO pin. > > > > > > > > > > > > > > > > > > The program i look for would be useful instead to > > > > > > > > > esablish > > > > > > > > > which physical pin has been configured as GPIO pin or > > > > > > > > > PWM, PRU, I2C etc. > > > > > > > > > > > > > > > > > > I asked also in the Forum, but the only one aswering > > > > > > > > > (@Phishry) has given me your same suggestion. > > > > > > > > > > > > > > > > > > If nobody knows of such a program i will start the > > > > > > > > > implementation, > > > > > > > > > maybe > > > > > > > > > tomorrow. > > > > > > > > > > > > > > > > > > bye > > > > > > > > > Nicola > > > > > > > > > > > > > > > > > Please bottom-post when replying to freebsd mailing > lists. > > > > > > > ok ! > > > > > > > > > > > > > > > > There is no interface defined for getting an fdt_pinctrl > > > > > > > > driver > > > > > > > > to > > > > > > > > return info about the current configuration. Even if > such > > > > > > > > an > > > > > > > > interface > > > > > > > > existed, there would also need to be a new driver > providing > > > > > > > > a > > > > > > > > cdev > > > > > > > > so > > > > > > > > that userland can access the information. > > > > > > > ok, no interface. > > > > > > > > > > > > > > > > There is also nothing in freebsd equivelent to the linux > > > > > > > > devmem2 > > > > > > > > program. A driver would have to be written to provide > > > > > > > > access to > > > > > > > > device- > > > > > > > > mapped memory before such a program could be > written. You > > > > > > > > can't > > > > > > > > access > > > > > > > > arm hardware registers via /dev/mem or /dev/kmem. > > > > > > > > > > > > > > > > -- Ian > > > > > > > I just compiled devmem2 and it seems to work. I did silly > > > > > > > modifications. > > > > > > > The code is here: http://euriscom.it/data/dm2.c > > > > > > > (forget the first comment lines, they are poor, I did not > > > > > > > intend > > > > > > > to > > > > > > > share this, it is my working copy) > > > > > > > > > > > > > > if i run it: > > > > > > > --------------------------------- > > > > > > > #> ./dm2 0x44e10998 b > > > > > > > /dev/mem opened. > > > > > > > Memory mapped at address 0x20221000. > > > > > > > Value at address 0x44E10998 (0x20221998): 0x5 > > > > > > > --------------------------------- > > > > > > > > > > > > > > Whic corresponds to what i wrote in the DTO. > > > > > > > ----- > > > > > > >               pru_pru_pins: pinmux_pru_pru_pins { > > > > > > > pinctrl-single,pins = < > > > > > > > // 0x1a4 0x05   /* P9.27 > > > > > > > pr1_pru0_pru_r30_5, > > > > > > > Mode 5 output pull-down   */ > > > > > > > 0x19c 0x26   /* P9.28 > > > > > > > pr1_pru0_pru_r31_3, > > > > > > > Mode 6 input pull-down    */ > > > > > > > 0x198 0x05    /* PRU0-2 -- P9.30 > > > > > > > -- > > > > > > > pr1_pru0_pru_r30_2 ... se in MODE-5  */ > > > > > > > >; > > > > > > >                      }; > > > > > > > ----- > > > > > > > > > > > > > > This is the only test i made but it seems improbable I got > > > > > > > the > > > > > > > same > > > > > > > value by chance;) > > > > > > > > > > > > > > It goes without saying that I don't understand all what i > > > > > > > wrote, > > > > > > > so, i could be boldly wrong ;) > > > > > > > > > > > > > > If it turns out it works let me know, i can make the port. > > > > > > > > > > > > > > bye > > > > > > > n. > > > > > > You might accidentally get /dev/mem access to work, but it's > > > > > > not by > > > > > > design. The rules of the arm memory model forbid mapping the > > > > > > same > > > > > > physical memory to different virtual addresses using > different > > > > > > attributes (normal cacheable memory versus Device > memory), and > > > > > > I > > > > > > don't > > > > > > see anything in the arm devmem code that handles memory > > > > > > attributes. > > > > > > > > > > > > -- Ian > > > > > I would like to discuss more this thing but really, i am too > > > > > ignorant > > > > > on > > > > > this subject. > > > > > > > > > > What i can say is this, I learnt to use devmem2 from D.Molloy > > > > > book > > > > > "Exploring BeagleBone", > > > > > see pg. 218. The author says this way "bypasses the Linux > OS". I > > > > > used > > > > > the thing > > > > > in Linux, it works, as it seems to do in FreeBSD-12-APLHA. > > > > > > > > > > If can tell you also I remember i used it one day in FreeBSD- > > > > > 11.1, > > > > > it > > > > > was working. > > > > > > > > > > I don't have the background to go deeper. > > > > > > > > > > If you can understand why it works and establish that it is > > > > > realiable > > > > > (even only for reading) let me (us) know ! ;) > > > > > > > > > > bye > > > > > n. > > > > > > > > > I think it should be possible to do a bit of kernel work to > change > > > > it > > > > from "works by accident" to "does the right thing", except > I'm not > > > > sure > > > > it'll be possible to automatically detect when Device memory is > > > > being > > > > accessed/mapped. It may be necessary to use the mem(4) ioctls to > > > > set > > > > the region to MDF_UNCACHEABLE, or even better, define a new > > > > MDF_MMIO > > > > for mapping ranges of device registers that arm systems have to > > > > treat > > > > as memory type Device. I'll look into it when I have some time. > > > > > > > > -- Ian > > > Hi, > > > > > > After a suggestion from @Phisfry on the forum I guess found a way > > > to bypass the need of devmem2 to write my "pinfunc" utlity. > > > > > > I can read (all?) pin configurations from "ofwdump -a -p", > indeed I > > > see > > > blocks > > > like this: > > > ---------------------- > > > #> ofwdump -a -p > > > ---------- > > >    Node 0x30f4: pinmux_ehrpwm0_AB_pins > > >              phandle: > > >                00 00 00 ce > > >              pinctrl-single,pins: > > >                00 00 01 54 00 00 00 03 00 00 01 50 00 00 00 03 > > > ---------- > > > > > > So I hopefully wrote my script to parse "ofwdump" and what i > got is > > > this, > > > > > > -------------------------- > > > #> pinfunc.rb > > > HEADER   NAME            MODE       FUNCTION > > > ... > > > P.9.10   SYS_RESETn      1          - > > > P.9.11   UART4_RXD       not-found > > > P.9.12   GPIO1_28        not-found > > > P.9.13   UART4_TXD       not-found > > > P.9.14   EHRPWM1A        not-found > > > P.9.15   GPIO1_16        not-found > > > P.9.16   EHRPWM1B        not-found > > > P.9.17   I2C1_SCL        not-found > > > P.9.18   I2C1_SDA        not-found > > > P.9.19   I2C2_SCL        3          I2C2_SCL > > > P.9.20   I2C2_SDA        3          I2C2_SDA > > > P.9.21   UART2_TXD       3          ehrpwm0B > > > P.9.22   UART2_RXD       3          ehrpwm0A > > > P.9.23   GPIO1_17        not-found > > > P.9.24   UART1_TXD       not-found > > > P.9.25   GPIO3_21        0          mcasp0_ahclkx > > > P.9.26   UART1_RXD       not-found > > > P.9.27   GPIO3_19        not-found > > > P.9.28   SPI1_CS0        6 pr1_pru0_pru_r31_3 > > > P.9.29   SPI1_D0         0          mcasp0_fsx > > > P.9.30   SPI1_D1         6 pr1_pru0_pru_r31_2 > > > P.9.31   SPI1_SCLK       0          mcasp0_aclkx > > > P.9.32   VADC > > > ... > > > --------------------------- > > > > > > The only isssue seems to be that GPIO pins do not appear. > > > I could fix the problem parsing the output of "gpioctl -f > /dev/gpioX/ > > > -l" > > > > > > But I have a couple of questions : > > > 1] Is there somewhare written the GPIO pins configuration in > > > "ofwdump" ? > > > 2] If it is not written there, what is the reason ? > > > 2.1] Where is the boot GPIO pins configuration written ? > > > 2.2] I looked also in "dtc -I dtb -O dts /boot/dtb/am335x- > > > boneblack.dtb > > > > > > > > less" > > > but at the best of my ability to read it I could not find the > GPIOs > > > configuration. > > > > > > bye > > > nico > > > > The pinctrl info in the fdt data is used to override pins from their > > default settings that the chip powers on with. So you have to start > > with empirical knowledge of that, and treat the fdt data as a set of > > modifications to it. Obviously the pin defaults are different > for every > > soc. > > > > In theory, the pinctrl data is not static, it can be changed at > > runtime. In practice, that rarely happens, and could only happen > if the > > node has multiple pinctrl-N properties so that the drivers can > switch > > between them. > > > > Rather than parsing the ascii output from ofwdump (a program that's > > hard to love in any way), you'd probably be better off reading the > > actual binary data (sysctl -b hw.fdt.dtb | yourprog), and parse it > > using libfdt. Hmm, do we distribute libfdt? I think not. It > should at > > least be a port even if it's not licensed properly to be distributed > > with the base system. > > This should work: > sysctl -b hw.fdt.dtb | dtc -I dtb -O dts > > > It would, but then you'd be left parsing the output. And to know > what's actually going on, you have to look at a bunch of nodes. It's a > lot easier to thread that with libfdt than it is to roll your own code > to do it. > > Warner Ok, I have a little monster script doing something, take a look here if you wish: https://github.com/nmingotti/pinfun/blob/master/pinfun.rb I will make some cleanings ASAP, now it is really more messy than Lionel. Also, it works only on header P9 for the moment. It requires Ruby (compiling it on the BBB will take a few hours). bye n. -- -------------------------- Dr. Nicola Mingotti R&D - Borghi Srl CTO - BondInsider -------------------------- From owner-freebsd-arm@freebsd.org Tue Sep 4 01:43:16 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DDCCFCE200 for ; Tue, 4 Sep 2018 01:43:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-21.consmr.mail.ne1.yahoo.com (sonic316-21.consmr.mail.ne1.yahoo.com [66.163.187.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2111480620 for ; Tue, 4 Sep 2018 01:43:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: X.YBDDMVM1khkNJ_RztQ34P9UEHNedIqVBHmPauEzQsW6esVUg0dyp_MxlQktN1 ZMr10geQpw7KpZ7mAVAOsH2phKefMv8_D4FVe.Mo2VTqY3t4c8GeGgsd.h9h2iEuJVPDokt4Kbzh 9lf3TSp9ykPIRsfWZa_qJVPHD_Bc.vsc2MKKp0lWirwZtGjL5ZQWc7eB.dwutc1zGJaPlQJuwYZL rC_XhdjifS2_hn8WaL3JIWhr_FVSRzreIzLGQgTSHiznBcGj_LgSWsAax2ayfZEmO9bcapICyAL0 ov1m0qKs4pKwxcfQfvNtKjoTsbkA41CPjg5pr2TCf8ekfAcoCb_B_cvsUEVpxm.200J0R3ZD97JL biYVj1SOnDaPcLpgH3sq.k5NBdTokUlYGNTLRD8x20ImTPeRmHudb2tSj0cEfM2riFDdTHX5Rg.v 0v5IOPWi3HdfafEYYYcFXDEXNkeCEQBbmCkbjqNxjMQ7Jn3jYtmtCMhYuYeQ5MtG_Er54VSpoIrn 3j8hSZB5hstY.58HH4RuYApZbp3uyWNxl1GPJvpRpb4DSLA2ErhKSVB6kJTq4OTQPvct7T.QWmNS GdpNyy4wl2.60B46NJEkItT6cR0lHawheqTbSXjLUPNl0oQTWreo_90TW6lJl2U4oIWtCsL3ntUU IgWJxVvN9WGUBSO7_FPqRNtingiW__LqCzvO46CvKX3hUNduDjMZgl9W8RTk8DH8swV1JJyiyuqg uWB4F_Qhl9bWt24howxR8Bx4NLwrA0hPfBRwLSXQPG9PZweTlHfYHdxdmfYOj7NToPvlZ9rRBzb_ nh4tsGvrVMHa3x6wCQ6iScz6aHLDMEcus8cnhQFKKhPk7DojbepVPPJgiQLrebNMoFoQNtS130zC VhoUo_HUghRrklqpuIPFlkdSM2s.FGOIv6.I6lzvqzbWfmCSNbtT8RmFutAXH68MtvHt4rQahLhQ 1hQ_8Va2yei7t4hQyMWqxZGTKCoKGKLzCqBxXRBB0C22P22F9BNxdxY_ncl5JSknl3rOsoCsgmn7 J3FR0hw2ebRkFCVEJZB02SvAZqIcTYXTvznJ55w76uFgDk5Wg Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Tue, 4 Sep 2018 01:43:07 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp432.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d3e88e6b15b78c85a9835844719d040f for ; Tue, 04 Sep 2018 01:43:05 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: FYI: What a fairly-modern linux's /sys/kernel/debug/mmc0/ios reports on a Pine64+ 2GB for a Sandisk Ultra 128GB Micro SDXC UHS-I Card from a SDSQUAR-128G-GN6MA Message-Id: <52D448D7-C112-4C23-932C-16A5362E6844@yahoo.com> Date: Mon, 3 Sep 2018 18:43:03 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 01:43:16 -0000 [The Pine64+ 2GB focus is just because that is all I currently have access to for aarch64. I have no access to armv7 or such currently. The amd64 context is via virtualbox under macOS and so not relevant.] I finally have access to similar capacity microsdxc media to the previous e.MMC-on-adapter media that I had been using with the Pine64+ 2GB. The card tested for this is from a: Sandisk Ultra 128GB Micro SDXC UHS-I Card with Adapter = SDSQUAR-128G-GN6MA So I dd'd the fairly linux that I tested the e.MMC with over to the microsdxc. The linux is from: https://dl.armbian.com/pine64/Ubuntu_bionic_dev_nightly.7z which is: nightly mainline kernel master branch 4.17.y or 4.18.y It shows as: # uname -ap Linux pine64 4.18.0-rc4-sunxi64 #220 SMP Sun Jul 15 14:16:31 UTC 2018 = aarch64 aarch64 aarch64 GNU/Linux For the sdcard from the SDSQXBG-128G-GN6MA: # cat /sys/kernel/debug/mmc0/ios clock: 50000000 Hz actual clock: 50000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 2 (4 bits) timing spec: 2 (sd high-speed) signal voltage: 0 (3.30 V) driver type: 0 (driver type B) # hdparm -t /dev/mmcblk0 /dev/mmcblk0: Timing buffered disk reads: 70 MB in 3.07 seconds =3D 22.80 MB/sec (As I gather: all as expected.) For reference the e.MMC on an adapter used in the Pine64+ 2GB for this linux had shown: # cat /sys/kernel/debug/mmc0/ios clock: 52000000 Hz actual clock: 50000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 2 (4 bits) timing spec: 8 (mmc DDR52) signal voltage: 0 (3.30 V) driver type: 0 (driver type B) # hdparm -t /dev/mmcblk0 /dev/mmcblk0: Timing buffered disk reads: 134 MB in 3.04 seconds =3D 44.03 MB/sec (As I gather: this was surprising.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Sep 4 16:16:13 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27784FF3BD9 for ; Tue, 4 Sep 2018 16:16:13 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 96407756F4 for ; Tue, 4 Sep 2018 16:16:12 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id 56CFCFF3BD8; Tue, 4 Sep 2018 16:16:12 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34C1CFF3BD6 for ; Tue, 4 Sep 2018 16:16:12 +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 A626D756F2 for ; Tue, 4 Sep 2018 16:16:11 +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 b1d6c73b; Tue, 4 Sep 2018 18:16:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=gj3BRK0Z3R4XyYEFCQwY/jFeJ5U=; b=M4JwAgSOpxwTSL5utU2xvK0JCvKC EgmwDkyQP62e24iim4MY5n2YwcZC8w9t/0l8/+yqXRegrC0K2Ocvo4oJhtCaipf6 IW4o+7aBAeo80UqJQ0wuvBfmtL9pCs9RKNFSMFIqpkSq7IBjHG3geSc5qjgMh1o7 HPNT4DUevbqHN+o= 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=fgM3EwLIch5cPg8dndpryrTIx242HSMZcX38VDw4zrFCLYJ/g4lfaKMa fuXnlIRud8k4b1CWY+PoeITu3ChsYRpBPt9HlpQcI9jK/v0dzE8Iiv4lOqoPY0Cg H56FFJC32gZma573K3N8Kiou5ANrTQ9LKAMM1zF2SI67Dz8zr9g= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 29d465d0 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 4 Sep 2018 18:16:03 +0200 (CEST) Date: Tue, 4 Sep 2018 18:16:03 +0200 From: Emmanuel Vadot To: Daniel Braniss Cc: Jakob Alvermark , "freebsd-arm@freebsd.org" Subject: Re: allwinner/nanopi neo boot issues Message-Id: <20180904181603.916a3a6fbf05ecce149f6ea1@bidouilliste.com> In-Reply-To: <855C0010-888D-4988-8056-7788CBCF5A48@cs.huji.ac.il> References: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> <0fdbd315-f37d-e3d3-9309-612f53c4d379@alvermark.net> <8459A9BA-183A-461B-9050-3631C51218F9@cs.huji.ac.il> <474af48e-ba82-62ce-34a3-70dfc4382723@alvermark.net> <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> <03d4cb0a-c218-a186-936d-765261da2775@alvermark.net> <20180902172444.c4911c8c65a99a7d5e9fe8fa@bidouilliste.com> <4410f41b-79f5-f397-b0b1-84bceae82bd0@alvermark.net> <855C0010-888D-4988-8056-7788CBCF5A48@cs.huji.ac.il> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; 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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 16:16:13 -0000 On Mon, 3 Sep 2018 11:21:09 +0300 Daniel Braniss wrote: >=20 >=20 > > On 3 Sep 2018, at 11:05, Jakob Alvermark wrote: > >=20 > >=20 > > On 9/3/18 9:01 AM, Daniel Braniss wrote: > >>=20 > >>=20 > >>> On 2 Sep 2018, at 19:33, Jakob Alvermark > wrote: > >>>=20 > >>> On 9/2/18 5:24 PM, Emmanuel Vadot wrote: > >>>> On Sun, 2 Sep 2018 17:14:10 +0200 > >>>> Jakob Alvermark > w= rote: > >>>>=20 > >>>>> On 9/1/18 10:46 PM, Emmanuel Vadot wrote: > >>>>>> On Sat, 1 Sep 2018 15:50:25 +0200 > >>>>>> Jakob Alvermark >= wrote: > >>>>>>=20 > >>>>>>> On 8/29/18 2:22 PM, Daniel Braniss wrote: > >>>>>>>>> On 29 Aug 2018, at 15:17, Jakob Alvermark > >>>>>>>>> >> wrot= e: > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> On 8/24/18 10:02 AM, Daniel Braniss wrote: > >>>>>>>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss > >>>>>>>>>>> >> wr= ote: > >>>>>>>>>>>=20 > >>>>>>>>>>> hi, > >>>>>>>>>>> with the latest current r338243 no longer boots via ubldr, ef= i does > >>>>>>>>>>> but with overlays I have to manually enter the root partition. > >>>>>>>>>>>=20 > >>>>>>>>>>> this is where it hangs via ubldr: > >>>>>>>>>>>=20 > >>>>>>>>>>> Autoboot in 8 seconds, hit [Enter] to boot or any other key t= o stop > >>>>>>>>>>>=20 > >>>>>>>>>>> Loading kernel... > >>>>>>>>>>> /boot/kernel/kernel text=3D0x8a0950 data=3D0xae160+0x184520 > >>>>>>>>>>> syms=3D[0x4+0xa6d70+0x4+0x109f17] > >>>>>>>>>>> Loading configured modules... > >>>>>>>>>>> /boot/entropy size=3D0x1000 > >>>>>>>>>>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x601b > >>>>>>>>>>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. > >>>>>>>>>>> Kernel entry at 0x42400180... > >>>>>>>>>>> Kernel args: (null) > >>>>>>>>>>>=20 > >>>>>>>>>>> older - r337232 - boots fine, > >>>>>>>>>>>=20 > >>>>>>>>>>> any ideas where to look? > >>>>>>>>>> should have done an update before writing! > >>>>>>>>>>=20 > >>>>>>>>>> with the latest (and greatest) all is back to normal! > >>>>>>>>>> so now on to test orange pi one(h3), nanopi neo 2 (h5) and nan= opi > >>>>>>>>>> neo a64 > >>>>>>>>>>=20 > >>>>>>>>>> thanks, > >>>>>>>>>> danny > >>>>>>>>> Hi, > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> I am trying to get an Orange Pi R1 going, I get the same. > >>>>>>>>>=20 > >>>>>>>>> Loading kernel... > >>>>>>>>> /boot/kernel/kernel text=3D0x89ee40 data=3D0xae620+0x1f5ba0 > >>>>>>>>> syms=3D[0x4+0xa6d20+0x4+0x109e51] > >>>>>>>>> Loading configured modules... > >>>>>>>>> Could not load one or more modules! > >>>>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 > >>>>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. > >>>>>>>>> Kernel entry at 0x42400180... > >>>>>>>>> Kernel args: (null) > >>>>>>>>>=20 > >>>>>>>>> This is at r338369. > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>> try booting via efi; > >>>>>>>> make sure to copy /boot/loader.efi to /boot/msdos/EFI/BOOT/boota= a64.efi > >>>>>>>> remove /boot/msdos/boot.scr > >>>>>>>> good luck, > >>>>>>>> danny > >>>>>>> I tried the ALPHA4 snapshot, this happens: > >>>>>>>=20 > >>>>>>> Hit any key to stop autoboot: 0 > >>>>>>> switch to partitions #0, OK > >>>>>>> mmc0 is current device > >>>>>>> Scanning mmc 0:1... > >>>>>>> 25395 bytes read in 4 ms (6.1 MiB/s) > >>>>>>> Found EFI removable media binary efi/boot/bootarm.efi > >>>>>>> Scanning disks on usb... > >>>>>>> Disk usb0 not ready > >>>>>>> Disk usb1 not ready > >>>>>>> Disk usb2 not ready > >>>>>>> Disk usb3 not ready > >>>>>>> Scanning disks on mmc... > >>>>>>> MMC Device 1 not found > >>>>>>> MMC Device 2 not found > >>>>>>> MMC Device 3 not found > >>>>>>> Found 3 disks > >>>>>>> 508704 bytes read in 26 ms (18.7 MiB/s) > >>>>>>> ## Starting EFI application at 42000000 ... > >>>>>>> Consoles: EFI console > >>>>>>> failed to allocate staging area: 14 > >>>>>>> failed to allocate staging area > >>>>>>> ## Application terminated, r =3D 5 So this is weird, it mean that loader.efi couldn't allocate some pages. I've just tried ALPHA4 on my orangepi-zero (closer board that I have), I've just overwritten u-boot using the port we have for it and the board boots just fine. How did you generate the image for this one ? Could you test with my method ? Thanks. > >>>>>>> EFI LOAD FAILED: continuing... > >>>>>>>=20 > >>>>>>>=20 > >>>>>>> Tried manually loading ubldr.bin: > >>>>>>>=20 > >>>>>>> =3D> fatload mmc 0 0x42000000 ubldr.bin > >>>>>>> 306972 bytes read in 15 ms (19.5 MiB/s) > >>>>>>> =3D> go 0x42000000 > >>>>>>> Loading kernel... > >>>>>>> /boot/kernel/kernel text=3D0x85d7f0 data=3D0xaf620+0x24e1e0 > >>>>>>> syms=3D[0x4+0xa87d0+0x4+0x10c603] > >>>>>>> Loading configured modules... > >>>>>>> /boot/kernel/umodem.ko text=3D0x1bf4 text=3D0x1320 data=3D0x1080+= 0xf88 > >>>>>>> syms=3D[0x4+0x1070+0x4+0xbcd] > >>>>>>> loading required module 'ucom' > >>>>>>> /boot/kernel/ucom.ko text=3D0x1f8c text=3D0x2e90 data=3D0x1080+0x= 17bc > >>>>>>> syms=3D[0x4+0x14f0+0x4+0xc5d] > >>>>>>> Could not load one or more modules! > >>>>>>>=20 > >>>>>>> Hit [Enter] to boot immediately, or any other key for command pro= mpt. > >>>>>>> Booting [/boot/kernel/kernel]... > >>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 > >>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. > >>>>>>> Kernel entry at 0x42400180... > >>>>>>> Kernel args: (null) > >>>>>>>=20 > >>>>>>> And then it reboots... > >>>>>> I've just re-introduce the cache patches for u-boot as it appear= s that > >>>>>> some boards needs them (I've probably tested the wrong unpatched u= -boot > >>>>>> when I removed them ...) so booting with ubldr.bin should work now. > >>>>>> For the EFI issue I don't really know what is happening. > >>>>>=20 > >>>>> Thanks! With the updated U-boot it now boots with ubldr.bin. > >>>>>=20 > >>>>> How can I make it do this automatically? > >>>> If you copy the boot.scr file from the port/package to the root of = the > >>>> fat partition this will load ubldr.bin directly. > >>>=20 > >>> Thanks again! It works! > >>>=20 > >>>=20 > >>>> I'm more interested to debug the efi problem, I'll try on a H2 boar= d. > >>>=20 > >>> If there is anything I can do to help let me know. > >>>=20 > >>> I tried with boot1.efi as /efi/boot/bootarm.efi: > >>>=20 > >>> ## Starting EFI application at 42000000 ... > >>> >> FreeBSD EFI boot block > >>> Loader path: /boot/loader.efi > >>>=20 > >>> Initializing modules: UFS > >>> Load Path: /\efi\boot\bootarm.efi > >>> Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,= 0x0)/HD(1,0x01,0,0x800,0x2000) > >>> Probing 3 block devices.....* done > >>> UFS found 1 partition > >>> Consoles: EFI console > >>> failed to allocate staging area: 14 > >>> failed to allocate staging area > >>> Failed to start image provided by UFS (5) > >>> panic: No bootable partitions found! > >>> ## Application terminated, r =3D 1 > >>> EFI LOAD FAILED: continuing? > >>=20 > >> shot in the dark: > >> I found out that if the root partition is not freebsd-ufs the efi boo= t failed. > >> do a gpart show, > >>=20 > >> mine looks like this: > >> neo-001> gpart show > >> =3D> 63 15523777 mmcsd0 MBR (7.4G) > >> 63 1985 - free - (993K) > >> 2048 102400 1 fat32lba [active] (50M) > >> 104448 6187008 2 freebsd (3.0G) > >> 6291456 9232384 - free - (4.4G) > >>=20 > >> =3D> 0 6187008 mmcsd0s2 BSD (3.0G) > >> 0 6187008 1 freebsd-ufs (3.0G) > >=20 > > Nope, mine looks almost the same: > >=20 > > =3D> 63 31116225 mmcsd0 MBR (15G) > > 63 1985 - free - (993K) > > 2048 8192 1 fat16 (4.0M) > > 10240 6144 - free - (3.0M) > > 16384 4177920 2 freebsd (2.0G) > > 4194304 26921984 - free - (13G) > >=20 > > =3D> 0 4177920 mmcsd0s2 BSD (2.0G) > > 0 4177920 1 freebsd-ufs (2.0G) > >=20 > > Interestingly, loading bootarm.efi(boot1.efi) manually gets me to the l= oader: > >=20 > >=20 >=20 > bootarm.efi should be a copy of loader.efi not boot1.efi as far as I know. Both should work. > > =3D> fatload mmc 0 0x42000000 efi/boot/bootarm.efi > > 39500 bytes read in 4 ms (9.4 MiB/s) > > =3D> bootefi 0x42000000 > > But it does not boot: > >=20 > > Type '?' for a list of commands, 'help' for more detailed help. > > OK load boot/kernel/kernel > > boot/kernel/kernel text=3D0x89ef08 data=3D0xae620+0x1f5aa0 syms=3D[0x4+= 0xa6d30+0x4+0x109e65] > > OK load -t dtb boot/dtb/sun8i-h2-plus-orangepi-r1.dtb =20 > > boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 > > OK boot > > Using DTB from loaded file 'boot/dtb/sun8i-h2-plus-orangepi-r1.dtb'. > > EHCI failed to shut down host controller. > > Kernel entry at 0x43000180... > > Kernel args: (null) > > modulep: 0xc0d03000 > > relocation_offset 0 > > --Hangs here-- >=20 --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Tue Sep 4 17:11:04 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E136FF5AB1 for ; Tue, 4 Sep 2018 17:11:04 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2806C77CF1 for ; Tue, 4 Sep 2018 17:11:04 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: by mailman.ysv.freebsd.org (Postfix) id E0897FF5AAF; Tue, 4 Sep 2018 17:11:03 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A62B9FF5AAE for ; Tue, 4 Sep 2018 17:11:03 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 3DA6977CE9 for ; Tue, 4 Sep 2018 17:11:03 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-42bc70d5.06-431-73746f70.bbcust.telenor.se ([213.112.188.66] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fxEqs-000IQP-Kf; Tue, 04 Sep 2018 19:10:54 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=cQJpvya5usjDPJKDFOthAr7LEiz/I7QlE0AAaL/h9mE=; b=YXx6l9CdYK/mUK28v9eDf7FDZJ 9iWAJeclikRAJJOxuRfzGa8fJznHoKe5qNLYWuvcD9zHTGgC/949Kblvcmj1O+vmopaxpIqEb/Hg9 004aFtJ2+FZvwoISSEzA9VxxtECmQP2x6u1zgo6XKLSG81PLKJAULa3lNS8FeuXiJQ7ewv1XYxEYG FPl083Pb5UBWrkiGw94lVOHsA3M2qmh/+fEkIXBgflglED81W+Hbi5jQgy06gvIGxn1KVSqPqOWSd yz6pxrcrwCv8/UIuU3LGY2rEzIUEgWwBCWOs2TnWgxQbuHJeD69VqyoBkj6CjvUJ3ipP/gNz1U0Zz +5Oi47CA==; Received: from [192.168.67.33] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fxEqs-000PIW-3v; Tue, 04 Sep 2018 19:10:54 +0200 Subject: Re: allwinner/nanopi neo boot issues To: Emmanuel Vadot , Daniel Braniss Cc: "freebsd-arm@freebsd.org" References: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> <0fdbd315-f37d-e3d3-9309-612f53c4d379@alvermark.net> <8459A9BA-183A-461B-9050-3631C51218F9@cs.huji.ac.il> <474af48e-ba82-62ce-34a3-70dfc4382723@alvermark.net> <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> <03d4cb0a-c218-a186-936d-765261da2775@alvermark.net> <20180902172444.c4911c8c65a99a7d5e9fe8fa@bidouilliste.com> <4410f41b-79f5-f397-b0b1-84bceae82bd0@alvermark.net> <855C0010-888D-4988-8056-7788CBCF5A48@cs.huji.ac.il> <20180904181603.916a3a6fbf05ecce149f6ea1@bidouilliste.com> From: Jakob Alvermark Message-ID: <79e69d73-b4f0-177a-15da-786c4101697a@alvermark.net> Date: Tue, 4 Sep 2018 19:10:53 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180904181603.916a3a6fbf05ecce149f6ea1@bidouilliste.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 17:11:04 -0000 On 9/4/18 6:16 PM, Emmanuel Vadot wrote: > On Mon, 3 Sep 2018 11:21:09 +0300 > Daniel Braniss wrote: > >> >>> On 3 Sep 2018, at 11:05, Jakob Alvermark wrote: >>> >>> >>> On 9/3/18 9:01 AM, Daniel Braniss wrote: >>>> >>>>> On 2 Sep 2018, at 19:33, Jakob Alvermark > wrote: >>>>> >>>>> On 9/2/18 5:24 PM, Emmanuel Vadot wrote: >>>>>> On Sun, 2 Sep 2018 17:14:10 +0200 >>>>>> Jakob Alvermark > wrote: >>>>>> >>>>>>> On 9/1/18 10:46 PM, Emmanuel Vadot wrote: >>>>>>>> On Sat, 1 Sep 2018 15:50:25 +0200 >>>>>>>> Jakob Alvermark > wrote: >>>>>>>> >>>>>>>>> On 8/29/18 2:22 PM, Daniel Braniss wrote: >>>>>>>>>>> On 29 Aug 2018, at 15:17, Jakob Alvermark >>>>>>>>>>> >> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 8/24/18 10:02 AM, Daniel Braniss wrote: >>>>>>>>>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss >>>>>>>>>>>>> >> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> hi, >>>>>>>>>>>>> with the latest current r338243 no longer boots via ubldr, efi does >>>>>>>>>>>>> but with overlays I have to manually enter the root partition. >>>>>>>>>>>>> >>>>>>>>>>>>> this is where it hangs via ubldr: >>>>>>>>>>>>> >>>>>>>>>>>>> Autoboot in 8 seconds, hit [Enter] to boot or any other key to stop >>>>>>>>>>>>> >>>>>>>>>>>>> Loading kernel... >>>>>>>>>>>>> /boot/kernel/kernel text=0x8a0950 data=0xae160+0x184520 >>>>>>>>>>>>> syms=[0x4+0xa6d70+0x4+0x109f17] >>>>>>>>>>>>> Loading configured modules... >>>>>>>>>>>>> /boot/entropy size=0x1000 >>>>>>>>>>>>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=0x601b >>>>>>>>>>>>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. >>>>>>>>>>>>> Kernel entry at 0x42400180... >>>>>>>>>>>>> Kernel args: (null) >>>>>>>>>>>>> >>>>>>>>>>>>> older - r337232 - boots fine, >>>>>>>>>>>>> >>>>>>>>>>>>> any ideas where to look? >>>>>>>>>>>> should have done an update before writing! >>>>>>>>>>>> >>>>>>>>>>>> with the latest (and greatest) all is back to normal! >>>>>>>>>>>> so now on to test orange pi one(h3), nanopi neo 2 (h5) and nanopi >>>>>>>>>>>> neo a64 >>>>>>>>>>>> >>>>>>>>>>>> thanks, >>>>>>>>>>>> danny >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I am trying to get an Orange Pi R1 going, I get the same. >>>>>>>>>>> >>>>>>>>>>> Loading kernel... >>>>>>>>>>> /boot/kernel/kernel text=0x89ee40 data=0xae620+0x1f5ba0 >>>>>>>>>>> syms=[0x4+0xa6d20+0x4+0x109e51] >>>>>>>>>>> Loading configured modules... >>>>>>>>>>> Could not load one or more modules! >>>>>>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333 >>>>>>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >>>>>>>>>>> Kernel entry at 0x42400180... >>>>>>>>>>> Kernel args: (null) >>>>>>>>>>> >>>>>>>>>>> This is at r338369. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> try booting via efi; >>>>>>>>>> make sure to copy /boot/loader.efi to /boot/msdos/EFI/BOOT/bootaa64.efi >>>>>>>>>> remove /boot/msdos/boot.scr >>>>>>>>>> good luck, >>>>>>>>>> danny >>>>>>>>> I tried the ALPHA4 snapshot, this happens: >>>>>>>>> >>>>>>>>> Hit any key to stop autoboot: 0 >>>>>>>>> switch to partitions #0, OK >>>>>>>>> mmc0 is current device >>>>>>>>> Scanning mmc 0:1... >>>>>>>>> 25395 bytes read in 4 ms (6.1 MiB/s) >>>>>>>>> Found EFI removable media binary efi/boot/bootarm.efi >>>>>>>>> Scanning disks on usb... >>>>>>>>> Disk usb0 not ready >>>>>>>>> Disk usb1 not ready >>>>>>>>> Disk usb2 not ready >>>>>>>>> Disk usb3 not ready >>>>>>>>> Scanning disks on mmc... >>>>>>>>> MMC Device 1 not found >>>>>>>>> MMC Device 2 not found >>>>>>>>> MMC Device 3 not found >>>>>>>>> Found 3 disks >>>>>>>>> 508704 bytes read in 26 ms (18.7 MiB/s) >>>>>>>>> ## Starting EFI application at 42000000 ... >>>>>>>>> Consoles: EFI console >>>>>>>>> failed to allocate staging area: 14 >>>>>>>>> failed to allocate staging area >>>>>>>>> ## Application terminated, r = 5 > So this is weird, it mean that loader.efi couldn't allocate some pages. > > I've just tried ALPHA4 on my orangepi-zero (closer board that I have), > I've just overwritten u-boot using the port we have for it and the > board boots just fine. > How did you generate the image for this one ? > Could you test with my method ? Thanks. Which image should I use? For ALPHA3 there is a GENERICSD image, but not for ALPHA4. I just tried with FreeBSD-12.0-ALPHA4-arm-armv7-CUBIEBOARD2-20180831-r338410.img dd the u-boot from the port (latest one, u-boot-orangepi_r1-2018.07_3) Put the SD card in and this happened: Hit any key to stop autoboot:  0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... 25395 bytes read in 3 ms (8.1 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi Scanning disks on usb... Disk usb0 not ready Disk usb1 not ready Disk usb2 not ready Disk usb3 not ready Scanning disks on mmc... MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Found 3 disks 508704 bytes read in 25 ms (19.4 MiB/s) ## Starting EFI application at 42000000 ... Consoles: EFI console failed to allocate staging area: 14 failed to allocate staging area ## Application terminated, r = 5 EFI LOAD FAILED: continuing... >>>>>>>>> EFI LOAD FAILED: continuing... >>>>>>>>> >>>>>>>>> >>>>>>>>> Tried manually loading ubldr.bin: >>>>>>>>> >>>>>>>>> => fatload mmc 0 0x42000000 ubldr.bin >>>>>>>>> 306972 bytes read in 15 ms (19.5 MiB/s) >>>>>>>>> => go 0x42000000 >>>>>>>>> Loading kernel... >>>>>>>>> /boot/kernel/kernel text=0x85d7f0 data=0xaf620+0x24e1e0 >>>>>>>>> syms=[0x4+0xa87d0+0x4+0x10c603] >>>>>>>>> Loading configured modules... >>>>>>>>> /boot/kernel/umodem.ko text=0x1bf4 text=0x1320 data=0x1080+0xf88 >>>>>>>>> syms=[0x4+0x1070+0x4+0xbcd] >>>>>>>>> loading required module 'ucom' >>>>>>>>> /boot/kernel/ucom.ko text=0x1f8c text=0x2e90 data=0x1080+0x17bc >>>>>>>>> syms=[0x4+0x14f0+0x4+0xc5d] >>>>>>>>> Could not load one or more modules! >>>>>>>>> >>>>>>>>> Hit [Enter] to boot immediately, or any other key for command prompt. >>>>>>>>> Booting [/boot/kernel/kernel]... >>>>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333 >>>>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >>>>>>>>> Kernel entry at 0x42400180... >>>>>>>>> Kernel args: (null) >>>>>>>>> >>>>>>>>> And then it reboots... >>>>>>>> I've just re-introduce the cache patches for u-boot as it appears that >>>>>>>> some boards needs them (I've probably tested the wrong unpatched u-boot >>>>>>>> when I removed them ...) so booting with ubldr.bin should work now. >>>>>>>> For the EFI issue I don't really know what is happening. >>>>>>> Thanks! With the updated U-boot it now boots with ubldr.bin. >>>>>>> >>>>>>> How can I make it do this automatically? >>>>>> If you copy the boot.scr file from the port/package to the root of the >>>>>> fat partition this will load ubldr.bin directly. >>>>> Thanks again! It works! >>>>> >>>>> >>>>>> I'm more interested to debug the efi problem, I'll try on a H2 board. >>>>> If there is anything I can do to help let me know. >>>>> >>>>> I tried with boot1.efi as /efi/boot/bootarm.efi: >>>>> >>>>> ## Starting EFI application at 42000000 ... >>>>>>> FreeBSD EFI boot block >>>>> Loader path: /boot/loader.efi >>>>> >>>>> Initializing modules: UFS >>>>> Load Path: /\efi\boot\bootarm.efi >>>>> Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USB(0x6,0x0)/HD(1,0x01,0,0x800,0x2000) >>>>> Probing 3 block devices.....* done >>>>> UFS found 1 partition >>>>> Consoles: EFI console >>>>> failed to allocate staging area: 14 >>>>> failed to allocate staging area >>>>> Failed to start image provided by UFS (5) >>>>> panic: No bootable partitions found! >>>>> ## Application terminated, r = 1 >>>>> EFI LOAD FAILED: continuing? >>>> shot in the dark: >>>> I found out that if the root partition is not freebsd-ufs the efi boot failed. >>>> do a gpart show, >>>> >>>> mine looks like this: >>>> neo-001> gpart show >>>> => 63 15523777 mmcsd0 MBR (7.4G) >>>> 63 1985 - free - (993K) >>>> 2048 102400 1 fat32lba [active] (50M) >>>> 104448 6187008 2 freebsd (3.0G) >>>> 6291456 9232384 - free - (4.4G) >>>> >>>> => 0 6187008 mmcsd0s2 BSD (3.0G) >>>> 0 6187008 1 freebsd-ufs (3.0G) >>> Nope, mine looks almost the same: >>> >>> => 63 31116225 mmcsd0 MBR (15G) >>> 63 1985 - free - (993K) >>> 2048 8192 1 fat16 (4.0M) >>> 10240 6144 - free - (3.0M) >>> 16384 4177920 2 freebsd (2.0G) >>> 4194304 26921984 - free - (13G) >>> >>> => 0 4177920 mmcsd0s2 BSD (2.0G) >>> 0 4177920 1 freebsd-ufs (2.0G) >>> >>> Interestingly, loading bootarm.efi(boot1.efi) manually gets me to the loader: >>> >>> >> bootarm.efi should be a copy of loader.efi not boot1.efi as far as I know. > Both should work. > >>> => fatload mmc 0 0x42000000 efi/boot/bootarm.efi >>> 39500 bytes read in 4 ms (9.4 MiB/s) >>> => bootefi 0x42000000 >>> But it does not boot: >>> >>> Type '?' for a list of commands, 'help' for more detailed help. >>> OK load boot/kernel/kernel >>> boot/kernel/kernel text=0x89ef08 data=0xae620+0x1f5aa0 syms=[0x4+0xa6d30+0x4+0x109e65] >>> OK load -t dtb boot/dtb/sun8i-h2-plus-orangepi-r1.dtb >>> boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333 >>> OK boot >>> Using DTB from loaded file 'boot/dtb/sun8i-h2-plus-orangepi-r1.dtb'. >>> EHCI failed to shut down host controller. >>> Kernel entry at 0x43000180... >>> Kernel args: (null) >>> modulep: 0xc0d03000 >>> relocation_offset 0 >>> --Hangs here-- > From owner-freebsd-arm@freebsd.org Wed Sep 5 12:41:13 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D13EFEEDBF for ; Wed, 5 Sep 2018 12:41:13 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C7FFB7F5ED for ; Wed, 5 Sep 2018 12:41:12 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id 89B3AFEEDBE; Wed, 5 Sep 2018 12:41:12 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 678FDFEEDBD for ; Wed, 5 Sep 2018 12:41:12 +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 DE8E17F5EB for ; Wed, 5 Sep 2018 12:41:11 +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 866a404e; Wed, 5 Sep 2018 14:41:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=kPSgehajyUYP0YaXsUXX38WWjyE=; b=BwhNGbC6VquYAFgqkSYdOl3+Gx5g VzCLXhuZgB/x6VdHsJt/CA168WS0GEGB4/pLz16OG7KBuXOrzKDeB9X1IPXtHqZB ayPUmRnWfFl50VA094P7dCV4kgUixN1bVZDA/FhX9iuQWmoApj9c7jpXWQGXKKKF N4zFxX6BhGImJto= 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=FxIZwAT+2/Dr9rOpgm0EqUEu+ybvyVrSqq965Pxc5J2QTRJwd32qwBYk 2NNiRC5lORPuBEGVtwYDH02VuDAHBA05M6VRgzDTO9nM2s/z+L31g67/jIVnOREr GfRFI4ejxAYwKfDa+cOa3a54upaIz2yebFXSIUeIQvKUai3+mYg= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id feadd25d TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 5 Sep 2018 14:41:09 +0200 (CEST) Date: Wed, 5 Sep 2018 14:41:08 +0200 From: Emmanuel Vadot To: Jakob Alvermark Cc: Daniel Braniss , "freebsd-arm@freebsd.org" Subject: Re: allwinner/nanopi neo boot issues Message-Id: <20180905144108.7a2e361108cdcf3c16ed8b66@bidouilliste.com> In-Reply-To: <79e69d73-b4f0-177a-15da-786c4101697a@alvermark.net> References: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> <0fdbd315-f37d-e3d3-9309-612f53c4d379@alvermark.net> <8459A9BA-183A-461B-9050-3631C51218F9@cs.huji.ac.il> <474af48e-ba82-62ce-34a3-70dfc4382723@alvermark.net> <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> <03d4cb0a-c218-a186-936d-765261da2775@alvermark.net> <20180902172444.c4911c8c65a99a7d5e9fe8fa@bidouilliste.com> <4410f41b-79f5-f397-b0b1-84bceae82bd0@alvermark.net> <855C0010-888D-4988-8056-7788CBCF5A48@cs.huji.ac.il> <20180904181603.916a3a6fbf05ecce149f6ea1@bidouilliste.com> <79e69d73-b4f0-177a-15da-786c4101697a@alvermark.net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; 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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 12:41:13 -0000 On Tue, 4 Sep 2018 19:10:53 +0200 Jakob Alvermark wrote: > On 9/4/18 6:16 PM, Emmanuel Vadot wrote: > > On Mon, 3 Sep 2018 11:21:09 +0300 > > Daniel Braniss wrote: > > > >> > >>> On 3 Sep 2018, at 11:05, Jakob Alvermark wrote: > >>> > >>> > >>> On 9/3/18 9:01 AM, Daniel Braniss wrote: > >>>> > >>>>> On 2 Sep 2018, at 19:33, Jakob Alvermark > wrote: > >>>>> > >>>>> On 9/2/18 5:24 PM, Emmanuel Vadot wrote: > >>>>>> On Sun, 2 Sep 2018 17:14:10 +0200 > >>>>>> Jakob Alvermark >= wrote: > >>>>>> > >>>>>>> On 9/1/18 10:46 PM, Emmanuel Vadot wrote: > >>>>>>>> On Sat, 1 Sep 2018 15:50:25 +0200 > >>>>>>>> Jakob Alvermark > wrote: > >>>>>>>> > >>>>>>>>> On 8/29/18 2:22 PM, Daniel Braniss wrote: > >>>>>>>>>>> On 29 Aug 2018, at 15:17, Jakob Alvermark > >>>>>>>>>>> >> wr= ote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On 8/24/18 10:02 AM, Daniel Braniss wrote: > >>>>>>>>>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss > >>>>>>>>>>>>> >> = wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> hi, > >>>>>>>>>>>>> with the latest current r338243 no longer boots via ubldr, = efi does > >>>>>>>>>>>>> but with overlays I have to manually enter the root partiti= on. > >>>>>>>>>>>>> > >>>>>>>>>>>>> this is where it hangs via ubldr: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Autoboot in 8 seconds, hit [Enter] to boot or any other key= to stop > >>>>>>>>>>>>> > >>>>>>>>>>>>> Loading kernel... > >>>>>>>>>>>>> /boot/kernel/kernel text=3D0x8a0950 data=3D0xae160+0x184520 > >>>>>>>>>>>>> syms=3D[0x4+0xa6d70+0x4+0x109f17] > >>>>>>>>>>>>> Loading configured modules... > >>>>>>>>>>>>> /boot/entropy size=3D0x1000 > >>>>>>>>>>>>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x601b > >>>>>>>>>>>>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. > >>>>>>>>>>>>> Kernel entry at 0x42400180... > >>>>>>>>>>>>> Kernel args: (null) > >>>>>>>>>>>>> > >>>>>>>>>>>>> older - r337232 - boots fine, > >>>>>>>>>>>>> > >>>>>>>>>>>>> any ideas where to look? > >>>>>>>>>>>> should have done an update before writing! > >>>>>>>>>>>> > >>>>>>>>>>>> with the latest (and greatest) all is back to normal! > >>>>>>>>>>>> so now on to test orange pi one(h3), nanopi neo 2 (h5) and n= anopi > >>>>>>>>>>>> neo a64 > >>>>>>>>>>>> > >>>>>>>>>>>> thanks, > >>>>>>>>>>>> danny > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I am trying to get an Orange Pi R1 going, I get the same. > >>>>>>>>>>> > >>>>>>>>>>> Loading kernel... > >>>>>>>>>>> /boot/kernel/kernel text=3D0x89ee40 data=3D0xae620+0x1f5ba0 > >>>>>>>>>>> syms=3D[0x4+0xa6d20+0x4+0x109e51] > >>>>>>>>>>> Loading configured modules... > >>>>>>>>>>> Could not load one or more modules! > >>>>>>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 > >>>>>>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. > >>>>>>>>>>> Kernel entry at 0x42400180... > >>>>>>>>>>> Kernel args: (null) > >>>>>>>>>>> > >>>>>>>>>>> This is at r338369. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> try booting via efi; > >>>>>>>>>> make sure to copy /boot/loader.efi to /boot/msdos/EFI/BOOT/boo= taa64.efi > >>>>>>>>>> remove /boot/msdos/boot.scr > >>>>>>>>>> good luck, > >>>>>>>>>> danny > >>>>>>>>> I tried the ALPHA4 snapshot, this happens: > >>>>>>>>> > >>>>>>>>> Hit any key to stop autoboot: 0 > >>>>>>>>> switch to partitions #0, OK > >>>>>>>>> mmc0 is current device > >>>>>>>>> Scanning mmc 0:1... > >>>>>>>>> 25395 bytes read in 4 ms (6.1 MiB/s) > >>>>>>>>> Found EFI removable media binary efi/boot/bootarm.efi > >>>>>>>>> Scanning disks on usb... > >>>>>>>>> Disk usb0 not ready > >>>>>>>>> Disk usb1 not ready > >>>>>>>>> Disk usb2 not ready > >>>>>>>>> Disk usb3 not ready > >>>>>>>>> Scanning disks on mmc... > >>>>>>>>> MMC Device 1 not found > >>>>>>>>> MMC Device 2 not found > >>>>>>>>> MMC Device 3 not found > >>>>>>>>> Found 3 disks > >>>>>>>>> 508704 bytes read in 26 ms (18.7 MiB/s) > >>>>>>>>> ## Starting EFI application at 42000000 ... > >>>>>>>>> Consoles: EFI console > >>>>>>>>> failed to allocate staging area: 14 > >>>>>>>>> failed to allocate staging area > >>>>>>>>> ## Application terminated, r =3D 5 > > So this is weird, it mean that loader.efi couldn't allocate some page= s. > > > > I've just tried ALPHA4 on my orangepi-zero (closer board that I have), > > I've just overwritten u-boot using the port we have for it and the > > board boots just fine. > > How did you generate the image for this one ? > > Could you test with my method ? Thanks. >=20 > Which image should I use? For ALPHA3 there is a GENERICSD image, but not= =20 > for ALPHA4. Build fail due to some (maybe) race condition. > I just tried with=20 > FreeBSD-12.0-ALPHA4-arm-armv7-CUBIEBOARD2-20180831-r338410.img Any of the armv7 image will do, they are all the same except the u-boot part. > dd the u-boot from the port (latest one, u-boot-orangepi_r1-2018.07_3) >=20 > Put the SD card in and this happened: >=20 > Hit any key to stop autoboot:=A0 0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > 25395 bytes read in 3 ms (8.1 MiB/s) > Found EFI removable media binary efi/boot/bootarm.efi > Scanning disks on usb... > Disk usb0 not ready > Disk usb1 not ready > Disk usb2 not ready > Disk usb3 not ready > Scanning disks on mmc... > MMC Device 1 not found > MMC Device 2 not found > MMC Device 3 not found > Found 3 disks > 508704 bytes read in 25 ms (19.4 MiB/s) > ## Starting EFI application at 42000000 ... > Consoles: EFI console > failed to allocate staging area: 14 > failed to allocate staging area > ## Application terminated, r =3D 5 > EFI LOAD FAILED: continuing... >=20 >=20 Could you try to decrease EFI_STAGING_SIZE to 32 in stand/efi/loader/copy.c ? We currently request 64M for the staging size which seems to be too big for this board. U-Boot cannot find enough memory it seems, https://elixir.bootlin.com/u-boot/latest/source/lib/efi_loader/efi_memory.c= #L300 --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Sep 5 15:25:00 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16499FF3ACB for ; Wed, 5 Sep 2018 15:25:00 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 824EE85CA3 for ; Wed, 5 Sep 2018 15:24:59 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: by mailman.ysv.freebsd.org (Postfix) id 43A7EFF3ACA; Wed, 5 Sep 2018 15:24:59 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21A4BFF3AC9 for ; Wed, 5 Sep 2018 15:24:59 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 9F81585CA2 for ; Wed, 5 Sep 2018 15:24:58 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-42bc70d5.06-431-73746f70.bbcust.telenor.se ([213.112.188.66] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fxZfs-000JdT-0p; Wed, 05 Sep 2018 17:24:56 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=u9H/Cnqak93fsRVs8dZQP5R5TQQ4P+yyD1mv9kM9a6w=; b=lB9Mxz0/tOzlXseEVsRkcrhoz1 FWt/k0sIv0f4oqLuy0pJmycl3cb+WqqnQows+r06fIiy+bTRPTHwvNcn1z8s1AXPU8kcBj01AKhDF RexH6OqWvTwMzRRkrJlZrvtJFzdiyOxZKD0XrZzwSX/HW+ryKUTpBLZijCyPnol6DMhWMrnc4r7LU v9LXUkFvBS9Zc43DSAvOuWi0reg8ef4B2sTI/kx6mkoVGFWSL6X/LiK8BoFX2RfIlS4Hqi/z0elYT 807N2nUeSUTDFs2ORqSP2LgGWCy+LrGw/J6vYassg04SVdLcjEBomeC1dC70vmZraU7z/f56e3625 TX7HeqEg==; Received: from [94.136.80.38] (helo=[10.1.10.45]) by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fxZfr-000INg-E4; Wed, 05 Sep 2018 17:24:55 +0200 Subject: Re: allwinner/nanopi neo boot issues To: Emmanuel Vadot Cc: Daniel Braniss , "freebsd-arm@freebsd.org" References: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> <0fdbd315-f37d-e3d3-9309-612f53c4d379@alvermark.net> <8459A9BA-183A-461B-9050-3631C51218F9@cs.huji.ac.il> <474af48e-ba82-62ce-34a3-70dfc4382723@alvermark.net> <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> <03d4cb0a-c218-a186-936d-765261da2775@alvermark.net> <20180902172444.c4911c8c65a99a7d5e9fe8fa@bidouilliste.com> <4410f41b-79f5-f397-b0b1-84bceae82bd0@alvermark.net> <855C0010-888D-4988-8056-7788CBCF5A48@cs.huji.ac.il> <20180904181603.916a3a6fbf05ecce149f6ea1@bidouilliste.com> <79e69d73-b4f0-177a-15da-786c4101697a@alvermark.net> <20180905144108.7a2e361108cdcf3c16ed8b66@bidouilliste.com> From: Jakob Alvermark Message-ID: <6a6d0683-cb07-ec4d-77f8-418d84c41f08@alvermark.net> Date: Wed, 5 Sep 2018 17:24:54 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180905144108.7a2e361108cdcf3c16ed8b66@bidouilliste.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 15:25:00 -0000 On 9/5/18 2:41 PM, Emmanuel Vadot wrote: > On Tue, 4 Sep 2018 19:10:53 +0200 > Jakob Alvermark wrote: > >> On 9/4/18 6:16 PM, Emmanuel Vadot wrote: >>> On Mon, 3 Sep 2018 11:21:09 +0300 >>> Daniel Braniss wrote: >>> >>>>> On 3 Sep 2018, at 11:05, Jakob Alvermark wrote: >>>>> >>>>> >>>>> On 9/3/18 9:01 AM, Daniel Braniss wrote: >>>>>>> On 2 Sep 2018, at 19:33, Jakob Alvermark > wrote: >>>>>>> >>>>>>> On 9/2/18 5:24 PM, Emmanuel Vadot wrote: >>>>>>>> On Sun, 2 Sep 2018 17:14:10 +0200 >>>>>>>> Jakob Alvermark > wrote: >>>>>>>> >>>>>>>>> On 9/1/18 10:46 PM, Emmanuel Vadot wrote: >>>>>>>>>> On Sat, 1 Sep 2018 15:50:25 +0200 >>>>>>>>>> Jakob Alvermark > wrote: >>>>>>>>>> >>>>>>>>>>> On 8/29/18 2:22 PM, Daniel Braniss wrote: >>>>>>>>>>>>> On 29 Aug 2018, at 15:17, Jakob Alvermark >>>>>>>>>>>>> >> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 8/24/18 10:02 AM, Daniel Braniss wrote: >>>>>>>>>>>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss >>>>>>>>>>>>>>> >> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> hi, >>>>>>>>>>>>>>> with the latest current r338243 no longer boots via ubldr, efi does >>>>>>>>>>>>>>> but with overlays I have to manually enter the root partition. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> this is where it hangs via ubldr: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Autoboot in 8 seconds, hit [Enter] to boot or any other key to stop >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Loading kernel... >>>>>>>>>>>>>>> /boot/kernel/kernel text=0x8a0950 data=0xae160+0x184520 >>>>>>>>>>>>>>> syms=[0x4+0xa6d70+0x4+0x109f17] >>>>>>>>>>>>>>> Loading configured modules... >>>>>>>>>>>>>>> /boot/entropy size=0x1000 >>>>>>>>>>>>>>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=0x601b >>>>>>>>>>>>>>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. >>>>>>>>>>>>>>> Kernel entry at 0x42400180... >>>>>>>>>>>>>>> Kernel args: (null) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> older - r337232 - boots fine, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> any ideas where to look? >>>>>>>>>>>>>> should have done an update before writing! >>>>>>>>>>>>>> >>>>>>>>>>>>>> with the latest (and greatest) all is back to normal! >>>>>>>>>>>>>> so now on to test orange pi one(h3), nanopi neo 2 (h5) and nanopi >>>>>>>>>>>>>> neo a64 >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks, >>>>>>>>>>>>>> danny >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I am trying to get an Orange Pi R1 going, I get the same. >>>>>>>>>>>>> >>>>>>>>>>>>> Loading kernel... >>>>>>>>>>>>> /boot/kernel/kernel text=0x89ee40 data=0xae620+0x1f5ba0 >>>>>>>>>>>>> syms=[0x4+0xa6d20+0x4+0x109e51] >>>>>>>>>>>>> Loading configured modules... >>>>>>>>>>>>> Could not load one or more modules! >>>>>>>>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333 >>>>>>>>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >>>>>>>>>>>>> Kernel entry at 0x42400180... >>>>>>>>>>>>> Kernel args: (null) >>>>>>>>>>>>> >>>>>>>>>>>>> This is at r338369. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> try booting via efi; >>>>>>>>>>>> make sure to copy /boot/loader.efi to /boot/msdos/EFI/BOOT/bootaa64.efi >>>>>>>>>>>> remove /boot/msdos/boot.scr >>>>>>>>>>>> good luck, >>>>>>>>>>>> danny >>>>>>>>>>> I tried the ALPHA4 snapshot, this happens: >>>>>>>>>>> >>>>>>>>>>> Hit any key to stop autoboot: 0 >>>>>>>>>>> switch to partitions #0, OK >>>>>>>>>>> mmc0 is current device >>>>>>>>>>> Scanning mmc 0:1... >>>>>>>>>>> 25395 bytes read in 4 ms (6.1 MiB/s) >>>>>>>>>>> Found EFI removable media binary efi/boot/bootarm.efi >>>>>>>>>>> Scanning disks on usb... >>>>>>>>>>> Disk usb0 not ready >>>>>>>>>>> Disk usb1 not ready >>>>>>>>>>> Disk usb2 not ready >>>>>>>>>>> Disk usb3 not ready >>>>>>>>>>> Scanning disks on mmc... >>>>>>>>>>> MMC Device 1 not found >>>>>>>>>>> MMC Device 2 not found >>>>>>>>>>> MMC Device 3 not found >>>>>>>>>>> Found 3 disks >>>>>>>>>>> 508704 bytes read in 26 ms (18.7 MiB/s) >>>>>>>>>>> ## Starting EFI application at 42000000 ... >>>>>>>>>>> Consoles: EFI console >>>>>>>>>>> failed to allocate staging area: 14 >>>>>>>>>>> failed to allocate staging area >>>>>>>>>>> ## Application terminated, r = 5 >>> So this is weird, it mean that loader.efi couldn't allocate some pages. >>> >>> I've just tried ALPHA4 on my orangepi-zero (closer board that I have), >>> I've just overwritten u-boot using the port we have for it and the >>> board boots just fine. >>> How did you generate the image for this one ? >>> Could you test with my method ? Thanks. >> Which image should I use? For ALPHA3 there is a GENERICSD image, but not >> for ALPHA4. > Build fail due to some (maybe) race condition. > >> I just tried with >> FreeBSD-12.0-ALPHA4-arm-armv7-CUBIEBOARD2-20180831-r338410.img > Any of the armv7 image will do, they are all the same except the > u-boot part. > >> dd the u-boot from the port (latest one, u-boot-orangepi_r1-2018.07_3) >> >> Put the SD card in and this happened: >> >> Hit any key to stop autoboot:  0 >> switch to partitions #0, OK >> mmc0 is current device >> Scanning mmc 0:1... >> 25395 bytes read in 3 ms (8.1 MiB/s) >> Found EFI removable media binary efi/boot/bootarm.efi >> Scanning disks on usb... >> Disk usb0 not ready >> Disk usb1 not ready >> Disk usb2 not ready >> Disk usb3 not ready >> Scanning disks on mmc... >> MMC Device 1 not found >> MMC Device 2 not found >> MMC Device 3 not found >> Found 3 disks >> 508704 bytes read in 25 ms (19.4 MiB/s) >> ## Starting EFI application at 42000000 ... >> Consoles: EFI console >> failed to allocate staging area: 14 >> failed to allocate staging area >> ## Application terminated, r = 5 >> EFI LOAD FAILED: continuing... >> >> > Could you try to decrease EFI_STAGING_SIZE to 32 in > stand/efi/loader/copy.c ? Didn't make any difference: Found EFI removable media binary efi/boot/bootarm.efi Scanning disks on usb... Disk usb0 not ready Disk usb1 not ready Disk usb2 not ready Disk usb3 not ready Scanning disks on mmc... MMC Device 1 not found MMC Device 2 not found MMC Device 3 not found Found 3 disks 508704 bytes read in 26 ms (18.7 MiB/s) ## Starting EFI application at 42000000 ... Consoles: EFI console failed to allocate staging area: 14 failed to allocate staging area ## Application terminated, r = 5 EFI LOAD FAILED: continuing... > We currently request 64M for the staging size which seems to be too > big for this board. > U-Boot cannot find enough memory it seems, > https://elixir.bootlin.com/u-boot/latest/source/lib/efi_loader/efi_memory.c#L300 > From owner-freebsd-arm@freebsd.org Wed Sep 5 15:34:09 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50EE7FF3FAF for ; Wed, 5 Sep 2018 15:34:09 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DC82D86345 for ; Wed, 5 Sep 2018 15:34:08 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: by mailman.ysv.freebsd.org (Postfix) id A1546FF3FAE; Wed, 5 Sep 2018 15:34:08 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F623FF3FAC for ; Wed, 5 Sep 2018 15:34:08 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 1A07A86344 for ; Wed, 5 Sep 2018 15:34:07 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-42bc70d5.06-431-73746f70.bbcust.telenor.se ([213.112.188.66] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fxZok-000Jdx-SN; Wed, 05 Sep 2018 17:34:06 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:References:Cc:To:From:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=jRahvfEAg+9S1SVfJmyjb1kHUtC/51YA3vVkuFZMJpw=; b=DbDoKiJu0eVp3Bu2FsZ0oVLNVL d6GX7hvfhRuBerrNfHRM9J31k1d9LQM6bnWwtWZnQjI4PafPyAasksTTx3bz2FVpqQkv5xEmxrJ6p 9XZyApvl7kCNpdqGbBEqUzW5M4I5eEHPEXLvZdiT8+j0ECzcPuJmwN5w2TpttqpIO5G+ssKVz3Z/t yBsntu8IEkPUuib4aWhjpCJ0X675Sd1p6djrEqkGTDNgwaxbJ6sq7JaIobEQa2p3sfzctbzdcch3H mgXFezNj7Kz4FgZW4iFsJfGa6VAud8f1KJ0n8nrM8gAKoOUgvXJmVaWXaQEcz8JBaI5mybrSvA4wr Pw73iTjw==; Received: from [94.136.80.38] (helo=[10.1.10.45]) by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1fxZok-000ISU-CB; Wed, 05 Sep 2018 17:34:06 +0200 Subject: Re: allwinner/nanopi neo boot issues From: Jakob Alvermark To: Emmanuel Vadot Cc: "freebsd-arm@freebsd.org" References: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> <0fdbd315-f37d-e3d3-9309-612f53c4d379@alvermark.net> <8459A9BA-183A-461B-9050-3631C51218F9@cs.huji.ac.il> <474af48e-ba82-62ce-34a3-70dfc4382723@alvermark.net> <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> <03d4cb0a-c218-a186-936d-765261da2775@alvermark.net> <20180902172444.c4911c8c65a99a7d5e9fe8fa@bidouilliste.com> <4410f41b-79f5-f397-b0b1-84bceae82bd0@alvermark.net> <855C0010-888D-4988-8056-7788CBCF5A48@cs.huji.ac.il> <20180904181603.916a3a6fbf05ecce149f6ea1@bidouilliste.com> <79e69d73-b4f0-177a-15da-786c4101697a@alvermark.net> <20180905144108.7a2e361108cdcf3c16ed8b66@bidouilliste.com> <6a6d0683-cb07-ec4d-77f8-418d84c41f08@alvermark.net> Message-ID: <9a911ee0-379f-d8b0-a71a-7b5302d9e5d4@alvermark.net> Date: Wed, 5 Sep 2018 17:34:05 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <6a6d0683-cb07-ec4d-77f8-418d84c41f08@alvermark.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 15:34:09 -0000 On 9/5/18 5:24 PM, Jakob Alvermark wrote: > > On 9/5/18 2:41 PM, Emmanuel Vadot wrote: >> On Tue, 4 Sep 2018 19:10:53 +0200 >> Jakob Alvermark wrote: >> >>> On 9/4/18 6:16 PM, Emmanuel Vadot wrote: >>>> On Mon, 3 Sep 2018 11:21:09 +0300 >>>> Daniel Braniss wrote: >>>> >>>>>> On 3 Sep 2018, at 11:05, Jakob Alvermark >>>>>> wrote: >>>>>> >>>>>> >>>>>> On 9/3/18 9:01 AM, Daniel Braniss wrote: >>>>>>>> On 2 Sep 2018, at 19:33, Jakob Alvermark >>>>>>> > wrote: >>>>>>>> >>>>>>>> On 9/2/18 5:24 PM, Emmanuel Vadot wrote: >>>>>>>>> On Sun, 2 Sep 2018 17:14:10 +0200 >>>>>>>>> Jakob Alvermark >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> On 9/1/18 10:46 PM, Emmanuel Vadot wrote: >>>>>>>>>>> On Sat, 1 Sep 2018 15:50:25 +0200 >>>>>>>>>>> Jakob Alvermark >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> On 8/29/18 2:22 PM, Daniel Braniss wrote: >>>>>>>>>>>>>> On 29 Aug 2018, at 15:17, Jakob Alvermark >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 8/24/18 10:02 AM, Daniel Braniss wrote: >>>>>>>>>>>>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> hi, >>>>>>>>>>>>>>>> with the latest current r338243 no longer boots via >>>>>>>>>>>>>>>> ubldr, efi does >>>>>>>>>>>>>>>> but with overlays I have to manually enter the root >>>>>>>>>>>>>>>> partition. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> this is where it hangs via ubldr: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Autoboot in 8 seconds, hit [Enter] to boot or any other >>>>>>>>>>>>>>>> key to stop >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Loading kernel... >>>>>>>>>>>>>>>> /boot/kernel/kernel text=0x8a0950 data=0xae160+0x184520 >>>>>>>>>>>>>>>> syms=[0x4+0xa6d70+0x4+0x109f17] >>>>>>>>>>>>>>>> Loading configured modules... >>>>>>>>>>>>>>>> /boot/entropy size=0x1000 >>>>>>>>>>>>>>>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=0x601b >>>>>>>>>>>>>>>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. >>>>>>>>>>>>>>>> Kernel entry at 0x42400180... >>>>>>>>>>>>>>>> Kernel args: (null) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> older - r337232 - boots fine, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> any ideas where to look? >>>>>>>>>>>>>>> should have done an update before writing! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> with the latest (and greatest) all is back to normal! >>>>>>>>>>>>>>> so now on to test orange pi one(h3), nanopi neo 2 (h5) >>>>>>>>>>>>>>> and nanopi >>>>>>>>>>>>>>> neo a64 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> thanks, >>>>>>>>>>>>>>> danny >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am trying to get an Orange Pi R1 going, I get the same. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Loading kernel... >>>>>>>>>>>>>> /boot/kernel/kernel text=0x89ee40 data=0xae620+0x1f5ba0 >>>>>>>>>>>>>> syms=[0x4+0xa6d20+0x4+0x109e51] >>>>>>>>>>>>>> Loading configured modules... >>>>>>>>>>>>>> Could not load one or more modules! >>>>>>>>>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=0x6333 >>>>>>>>>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. >>>>>>>>>>>>>> Kernel entry at 0x42400180... >>>>>>>>>>>>>> Kernel args: (null) >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is at r338369. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> try booting via efi; >>>>>>>>>>>>> make sure to copy /boot/loader.efi to >>>>>>>>>>>>> /boot/msdos/EFI/BOOT/bootaa64.efi >>>>>>>>>>>>> remove /boot/msdos/boot.scr >>>>>>>>>>>>> good luck, >>>>>>>>>>>>> danny >>>>>>>>>>>> I tried the ALPHA4 snapshot, this happens: >>>>>>>>>>>> >>>>>>>>>>>> Hit any key to stop autoboot:  0 >>>>>>>>>>>> switch to partitions #0, OK >>>>>>>>>>>> mmc0 is current device >>>>>>>>>>>> Scanning mmc 0:1... >>>>>>>>>>>> 25395 bytes read in 4 ms (6.1 MiB/s) >>>>>>>>>>>> Found EFI removable media binary efi/boot/bootarm.efi >>>>>>>>>>>> Scanning disks on usb... >>>>>>>>>>>> Disk usb0 not ready >>>>>>>>>>>> Disk usb1 not ready >>>>>>>>>>>> Disk usb2 not ready >>>>>>>>>>>> Disk usb3 not ready >>>>>>>>>>>> Scanning disks on mmc... >>>>>>>>>>>> MMC Device 1 not found >>>>>>>>>>>> MMC Device 2 not found >>>>>>>>>>>> MMC Device 3 not found >>>>>>>>>>>> Found 3 disks >>>>>>>>>>>> 508704 bytes read in 26 ms (18.7 MiB/s) >>>>>>>>>>>> ## Starting EFI application at 42000000 ... >>>>>>>>>>>> Consoles: EFI console >>>>>>>>>>>> failed to allocate staging area: 14 >>>>>>>>>>>> failed to allocate staging area >>>>>>>>>>>> ## Application terminated, r = 5 >>>>    So this is weird, it mean that loader.efi couldn't allocate some >>>> pages. >>>> >>>>    I've just tried ALPHA4 on my orangepi-zero (closer board that I >>>> have), >>>> I've just overwritten u-boot using the port we have for it and the >>>> board boots just fine. >>>>    How did you generate the image for this one ? >>>>    Could you test with my method ? Thanks. >>> Which image should I use? For ALPHA3 there is a GENERICSD image, but >>> not >>> for ALPHA4. >>   Build fail due to some (maybe) race condition. >> >>> I just tried with >>> FreeBSD-12.0-ALPHA4-arm-armv7-CUBIEBOARD2-20180831-r338410.img >>   Any of the armv7 image will do, they are all the same except the >> u-boot part. >> >>> dd the u-boot from the port (latest one, u-boot-orangepi_r1-2018.07_3) >>> >>> Put the SD card in and this happened: >>> >>> Hit any key to stop autoboot:  0 >>> switch to partitions #0, OK >>> mmc0 is current device >>> Scanning mmc 0:1... >>> 25395 bytes read in 3 ms (8.1 MiB/s) >>> Found EFI removable media binary efi/boot/bootarm.efi >>> Scanning disks on usb... >>> Disk usb0 not ready >>> Disk usb1 not ready >>> Disk usb2 not ready >>> Disk usb3 not ready >>> Scanning disks on mmc... >>> MMC Device 1 not found >>> MMC Device 2 not found >>> MMC Device 3 not found >>> Found 3 disks >>> 508704 bytes read in 25 ms (19.4 MiB/s) >>> ## Starting EFI application at 42000000 ... >>> Consoles: EFI console >>> failed to allocate staging area: 14 >>> failed to allocate staging area >>> ## Application terminated, r = 5 >>> EFI LOAD FAILED: continuing... >>> >>> >>   Could you try to decrease EFI_STAGING_SIZE to 32 in >> stand/efi/loader/copy.c ? > > Didn't make any difference: > > Found EFI removable media binary efi/boot/bootarm.efi > Scanning disks on usb... > Disk usb0 not ready > Disk usb1 not ready > Disk usb2 not ready > Disk usb3 not ready > Scanning disks on mmc... > MMC Device 1 not found > MMC Device 2 not found > MMC Device 3 not found > Found 3 disks > 508704 bytes read in 26 ms (18.7 MiB/s) > ## Starting EFI application at 42000000 ... > Consoles: EFI console > failed to allocate staging area: 14 > failed to allocate staging area > ## Application terminated, r = 5 > EFI LOAD FAILED: continuing... Disregard that. I copied the wrong file. I boots with EFI_STAGING_SIZE set 32. > >>   We currently request 64M for the staging size which seems to be too >> big for this board. >>   U-Boot cannot find enough memory it seems, >> https://elixir.bootlin.com/u-boot/latest/source/lib/efi_loader/efi_memory.c#L300 >> >> > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Sep 5 16:03:48 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD544FF4F99 for ; Wed, 5 Sep 2018 16:03:48 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 2AD9A8801A for ; Wed, 5 Sep 2018 16:03:47 +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 w85G3c6T000975 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Sep 2018 09:03:39 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w85G3cd7000974; Wed, 5 Sep 2018 09:03:38 -0700 (PDT) (envelope-from fbsd) Date: Wed, 5 Sep 2018 09:03:37 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Checking USB ports on RPI2 Message-ID: <20180905160337.GA818@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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 16:03:48 -0000 It looks as if one of the USB ports on an RPI2 has quit working. Other ports seem to work normally, is there test utility of some sort that can be used to explore in greater depth what might be going on? The machine had been idling largely unused for some weeks running FreeBSD www.zefox.com 11.2-STABLE FreeBSD 11.2-STABLE #0 r337511: Thu Aug 9 12:21:02 PDT 2018 bob@www.zefox.com:/usr/obj/usr/src/sys/RPI2 arm This morning there was a (very) brief power outage, just enough to scramble a few of the plug-in digital clocks in the house. The RPI2 was found stuck in single-user mode with /dev/da0 missing in /dev. Since /var, /tmp, /usr and swap all live on da0 that much made sense. A soft reboot from the serial console again got stuck in single-user, again with no /dev/da0. Power-cycling had the same result. Moving the flash drive to the adjacent USB port allowed a normal boot, putting it back in the old position re-created the previous failure. So, it seems the trouble is the port, not the flash drive. Initially I expected the failure to be in the drive, it has been in continuous use, mostly testing buildworld/kernel, for around two years. That the trouble seems to be in the RPI2 is a great surprise which I'd like to explore a little more carefully if it's possible. Viewed from the connector end of the Pi, with the Ethernet jack at the top, the bad port is upper right, the working port is upper left. There are three other RPI2's and one RPI3 in the cluster, the rest of which seem to be working normally. >From this I infer that the power outage was the trigger, but not the cause of the problem. Thanks for reading, and any ideas. bob prohaska From owner-freebsd-arm@freebsd.org Wed Sep 5 16:29:44 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57555FF5ADA for ; Wed, 5 Sep 2018 16:29:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDC1588D40 for ; Wed, 5 Sep 2018 16:29:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 4133A1AFE4 for ; Wed, 5 Sep 2018 16:29:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w85GThnS004640 for ; Wed, 5 Sep 2018 16:29:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w85GThOE004639 for freebsd-arm@FreeBSD.org; Wed, 5 Sep 2018 16:29:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 231178] Very slow IO with small block size Date: Wed, 05 Sep 2018 16:29:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: robert.david.public@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 16:29:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231178 Bug ID: 231178 Summary: Very slow IO with small block size Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: robert.david.public@gmail.com On raspberry pi3 aarch64, I have noticed very slow IO on any type of storage device (USB,mmc) when the block size is slow. Example execution of dd shows huge difference (>10x) pi-backup ~ # dd if=3D/dev/mmcsd0 of=3D/dev/zero bs=3D1M 3781+1 records in 3781+1 records out 3965190144 bytes transferred in 226.929478 secs (17473226 bytes/sec) pi-backup ~ # dd if=3D/dev/mmcsd0 of=3D/dev/zero bs=3D512 ^C981585+0 records in 981585+0 records out 502571520 bytes transferred in 375.254570 secs (1339282 bytes/sec) (Note I have stopped that, because it would take >half hour to read 4GB sd card) Similar results can be seen on USB hdd. This practically make speed of any = fs (UFS/ZFS) <1MB/s. For comparison this is results from Linux 4.14 rpi64 ~ # dd if=3D/dev/mmcblk0 of=3D/dev/zero bs=3D512 7744512+0 records in 7744512+0 records out 3965190144 bytes (4.0 GB, 3.7 GiB) copied, 178.385 s, 22.2 MB/s rpi64 ~ # dd if=3D/dev/mmcblk0 of=3D/dev/zero bs=3D1M 3781+1 records in 3781+1 records out 3965190144 bytes (4.0 GB, 3.7 GiB) copied, 168.359 s, 23.6 MB/s I do not expect FreeBSD be easily on par with Linux, but on the other side there seems to be huge bottleneck/contention somewhere. Since it is not driver specific (USB/mmc), I expect something in core kernel not optimized yet. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Wed Sep 5 23:21:32 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A4C5FCCD67 for ; Wed, 5 Sep 2018 23:21:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F0366781CA for ; Wed, 5 Sep 2018 23:21:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 49F791E914 for ; Wed, 5 Sep 2018 23:21:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w85NLVIg009258 for ; Wed, 5 Sep 2018 23:21:31 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w85NLVMn009254 for freebsd-arm@FreeBSD.org; Wed, 5 Sep 2018 23:21:31 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 231188] many functions are missing dtrace probe points Date: Wed, 05 Sep 2018 23:21:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jmg@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 23:21:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231188 Bug ID: 231188 Summary: many functions are missing dtrace probe points Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: jmg@FreeBSD.org on an arm64 box, many functions are not listed in dtrace -l. For example, = on my A64-LTS board, the awg_probe and many other functions are not listed: # dtrace -l | grep awg_ 3543 fbt kernel awg_init_locked entry 3544 fbt kernel awg_init_locked return 3545 fbt kernel awg_media_status entry 3546 fbt kernel awg_miibus_statchg entry I'd expect awg_probe and many others to be present. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Thu Sep 6 00:38:33 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3DB1FCF577 for ; Thu, 6 Sep 2018 00:38:33 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 33AEB7C0BC for ; Thu, 6 Sep 2018 00:38:33 +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 w860cUlY003300 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Sep 2018 17:38:31 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w860cTHm003299; Wed, 5 Sep 2018 17:38:30 -0700 (PDT) (envelope-from fbsd) Date: Wed, 5 Sep 2018 17:38:29 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap) Message-ID: <20180906003829.GC818@www.zefox.net> References: <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180901230233.GA42895@www.zefox.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 00:38:34 -0000 On Sat, Sep 01, 2018 at 04:02:33PM -0700, bob prohaska wrote: > > With r338342 and > vm.pageout_oom_seq="1024" > in /boot/loader.conf the RPI3 is a bit closer to a Mars Rover. > No panics, crashes or USB errors, -j4 buildworld runs to completion. > When swap usage goes over about 50% the system slows, but doesn't give up. > There are six 1 GB swap partitions available, 3 on USB and 3 on microSD. > > Log files are at > http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/ > for the combinations tried so far. > It looks as if using all six GB of swap doesn't cause any immediate problem, at least so long as swap usage stays relatively low, say 1.5 GB. In a final test, TRIM was turned on without catastrophe, though it had little to do given that all the busy filesystems were on USB. The penalty was about one hour extra (25 vs 24 hours) to run -j4 buildworld from a clean start. One chance observation caught my attention, however. I'd always thought the VM system would favor fast swap devices over slow, but the gstat log recorded this, visible at http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/3gbsd_3gbusb/trim_on/swapscript.log dT: 10.004s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 3 175 91 673 4.0 84 701 4.0 0 0 0.0 24.4 mmcsd0 4 173 88 693 106.6 86 723 176.5 0 0 0.0 103.4 da0 1 58 30 224 4.5 28 220 4.1 0 0 0.0 14.5 mmcsd0s2b 3 175 91 673 4.0 84 701 4.0 0 0 0.0 24.7 mmcsd0s2 1 58 30 223 4.0 28 244 3.8 0 0 0.0 14.0 mmcsd0s2d 1 59 31 227 3.7 28 237 4.3 0 0 0.0 14.9 mmcsd0s2e 2 57 28 235 140.2 28 236 103.8 0 0 0.0 186.1 da0a 0 56 28 224 178.4 28 222 35.9 0 0 0.0 131.5 da0b 2 59 31 234 9.4 28 240 59.1 0 0 0.0 99.5 da0d 0 0 0 0 0.0 0 3 15011 0 0 0.0 150.1 da0e 0 1 0 0 0.0 1 22 13376 0 0 0.0 147.8 da0g Tue Sep 4 15:07:39 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 236872 811704 23% /dev/mmcsd0s2b 1048576 221568 827008 21% /dev/da0d 1048576 218636 829940 21% /dev/da0a 1048576 222028 826548 21% /dev/mmcsd0s2d 1048576 221660 826916 21% /dev/mmcsd0s2e 1048576 221392 827184 21% Total 6291456 1342156 4949300 21% Sep 4 14:57:52 www sshd[41673]: error: Received disconnect from 103.207.39.197 port 64499:3: com.jcraft.jsch.JSchException: Auth cancel [preauth] Sep 4 15:04:19 www kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2217840, size: 12288 The system has lots of fast swap available on microSD, but is seemingly choking trying to use the slow swap on da0 _and_ run traffic to /usr and /var. Buildworld doesn't run any faster with less swap, so I don't think the oversupply is the problem. Is this expected behavior? Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Thu Sep 6 02:05:25 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 016B4FE3240 for ; Thu, 6 Sep 2018 02:05:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-12.consmr.mail.ne1.yahoo.com (sonic307-12.consmr.mail.ne1.yahoo.com [66.163.190.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7995580797 for ; Thu, 6 Sep 2018 02:05:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 1j4irzEVM1n5m490J0zjqTOM6iRWZrGYDdL3bxmfD_g99ys14NxAPyHDp5aDbmx c3MelA.78QaOOYEqakqLxULBfXvw1KEWxNJGzUFljvueFPo3TW_SwWd.bcTgKISG2cFHlfvXMO8h 6ZErgmefbF3ywe71kW.2SIS_pp_QJ_oUq3R0pTbJkrU0J.H8w0VQX8SCfd9ZWeZwefwSD4zRZepi hYI_ZFAVSYtAYIDYZ96zscq2fQFMkgArlHlOiSOzkM0f_wCuksApVhcelTbFTKRKbYxUI0HrndYY aGkAkA3c5eRfjfriJQ6_K2nG7SuYyZV2Skjf1bng8_N.INWvBjGeOWT0plPAfSEg8oz6im87NlhV i1T9ou6WE5uH0KHS5EabAjC9Uabkku3LO5xsy3C4YfA8P0HAFT2ILQYdsi9V4MSj3qsRcLWcKpv0 HKm564OYsCbqdvz2a5ox.VNTTQtHhBCInhvRPfSWg2EGRbF7MEnUwPdDog5VhgYGBJ90eApPSHkp Q4cfef.CrdZ7O76YCsxkgAXquOUra3pvorCUsD.WmmQj3eEjgEvuzWdEmV7hUt6plnb4oLZFz__4 8Q_IVo.bKyACyUxS_n0xZhx58R5PgC8h4pyrDEprvH3TsoCEEE2lyiH.d2UvrTlkolVhIP.EJYq_ fy4rV8SU80ixY0eeUpiNbbJYQ7UeUjsdX75HheApHHEKEQa6_jpLeYoR.QLqmvMkQhvs7QK43K1h vCpxOufp2cFPOacyVdYTCbbSXdPWasoQaV4.Xc9aoF85KJxwcTmcD7tbIQpIYc25lDezxc6z3dnx NGRgAmuLrZt6StedycqETCkD0PdCWi.r4mA9pH5AMiPpVDPR4CZkDDdd.s2b9ecWtqAXV.qwtyrH L7TgaugCyT2ka8ni2f99ZfcPMx2DNSbilq.T.nFVKMyZ_vw6ZFEk93mmYXfzWw_YwzKGKbzVbRDr h9VH8umDq1HIm9OP72p0H1q0EiBoys3ze.VkqRyw46tcrDZvHLuaJ2hR9fWu9PDLEVfrKVb95wEJ Ofxej.TE- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Thu, 6 Sep 2018 02:05:17 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp427.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 108d42328177c67bf89bbe60bf210b12; Thu, 06 Sep 2018 02:05:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap) From: Mark Millard In-Reply-To: <20180906003829.GC818@www.zefox.net> Date: Wed, 5 Sep 2018 19:05:11 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <20180906003829.GC818@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 02:05:25 -0000 [I've omitted Kirk McKusick as my notes are largely off subject for what he asked about for testing specific to his changes.] On 2018-Sep-5, at 5:38 PM, bob prohaska wrote: > On Sat, Sep 01, 2018 at 04:02:33PM -0700, bob prohaska wrote: >>=20 >> With r338342 and >> vm.pageout_oom_seq=3D"1024" >> in /boot/loader.conf the RPI3 is a bit closer to a Mars Rover. >> No panics, crashes or USB errors, -j4 buildworld runs to completion. >> When swap usage goes over about 50% the system slows, but doesn't = give up. >> There are six 1 GB swap partitions available, 3 on USB and 3 on = microSD. >>=20 >> Log files are at >> http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/ >> for the combinations tried so far. >>=20 >=20 > It looks as if using all six GB of swap doesn't cause any immediate = problem, > at least so long as swap usage stays relatively low, say 1.5 GB. In a = final > test, TRIM was turned on without catastrophe, though it had little to = do > given that all the busy filesystems were on USB. The penalty was about = one > hour extra (25 vs 24 hours) to run -j4 buildworld from a clean start. What UFS file systems with TRIM enabled were on some /dev/mmcsd0* ? Did you 1st use "fsck_ffs -E" on any of the file systems where trim would work? If I gather right, the "clean start" was on USB where TRIM during the clean would not be available. The extra swap space may have contributed to the extra time? Having more swap uses more kernel memory for keeping track of the swap if I understand right. That leaves less for other things. That could have consequences other than outright failure. Quoting "man 8 loader" related to kern.maxswzone : Note that swap metadata can be fragmented, which means = that the system can run out of space before it reaches the theoretical limit. Therefore, care should be taken to = not configure more swap than approximately half of the theoretical maximum. Running out of space for swap metadata can leave the = system in an unrecoverable state. This wording suggests not allocating 6 GiBytes of swap when 3.5 GiBytes is approximately half the theoretical maximum --even if the system does still operate with 6 GiBytes. (Note: The man page's reference to "eight times the amount of physical = memory" and such does not seem to apply to all platforms. And rpi2 V1.1 and an = rpi3 with the same amount of RAM get rather difference recommended figures according to the messages generated.) > One chance observation caught my attention, however. I'd always = thought > the VM system would favor fast swap devices over slow, but the gstat = log > recorded this, visible at > = http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/3gbsd_3gbusb/trim_on/swa= pscript.log >=20 >=20 >=20 > dT: 10.004s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name > 3 175 91 673 4.0 84 701 4.0 0 0 = 0.0 24.4 mmcsd0 > 4 173 88 693 106.6 86 723 176.5 0 0 = 0.0 103.4 da0 > 1 58 30 224 4.5 28 220 4.1 0 0 = 0.0 14.5 mmcsd0s2b > 3 175 91 673 4.0 84 701 4.0 0 0 = 0.0 24.7 mmcsd0s2 > 1 58 30 223 4.0 28 244 3.8 0 0 = 0.0 14.0 mmcsd0s2d > 1 59 31 227 3.7 28 237 4.3 0 0 = 0.0 14.9 mmcsd0s2e > 2 57 28 235 140.2 28 236 103.8 0 0 = 0.0 186.1 da0a > 0 56 28 224 178.4 28 222 35.9 0 0 = 0.0 131.5 da0b > 2 59 31 234 9.4 28 240 59.1 0 0 = 0.0 99.5 da0d > 0 0 0 0 0.0 0 3 15011 0 0 = 0.0 150.1 da0e > 0 1 0 0 0.0 1 22 13376 0 0 = 0.0 147.8 da0g Are there any examples of "d/s kBps ms/d" being non-zero? If they are always zero then no TRIMing likely happened. That in turn would make TRIM an unlikely use of an extra hour. > Tue Sep 4 15:07:39 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 236872 811704 23% > /dev/mmcsd0s2b 1048576 221568 827008 21% > /dev/da0d 1048576 218636 829940 21% > /dev/da0a 1048576 222028 826548 21% > /dev/mmcsd0s2d 1048576 221660 826916 21% > /dev/mmcsd0s2e 1048576 221392 827184 21% > Total 6291456 1342156 4949300 21% As I understand the normal use of multiple swap partitions is to split the load across channels that can operate independently in parallel. Having 3 such partitions on the same channel/device may only add overhead vs. one full-size partition per channel/device. I also do not know if mmcsd0 and da0 can have independent, parallel I/O activity in the rpi3 context. > Sep 4 14:57:52 www sshd[41673]: error: Received disconnect from = 103.207.39.197 port 64499:3: com.jcraft.jsch.JSchException: Auth cancel = [preauth] > Sep 4 15:04:19 www kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 2217840, size: 12288 Note: my context is very different from yours and I get no console messages about I/O or waits during buildworld buildkernel or other such build/install tests. > The system has lots of fast swap available on microSD, but is = seemingly choking=20 > trying to use the slow swap on da0 _and_ run traffic to /usr and /var. = Buildworld > doesn't run any faster with less swap, so I don't think the oversupply = is the problem. If I understand right, your only 6 GiByte swap experiment was slower but you attributed all time variations to an (inactive? ever used?) TRIM enabled status. You might want to manipulate the two separately. For all I know something else may also have contributed. I've no clue if having so many swap partitions on the same = channel/device has consequences that having only one per channel/device would avoid. > Is this expected behavior? =20 As I understand the approximately even split across the in-use swap partitions is the normal way things are split. It is the placement of the partitions themselves that contributes to how effective that split is at improving the swap/paging I/O if I understand right. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Sep 6 02:43:56 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EECEFE484D for ; Thu, 6 Sep 2018 02:43:56 +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 63293819BB for ; Thu, 6 Sep 2018 02:43:55 +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 w862hq0k058505; Wed, 5 Sep 2018 19:43:52 -0700 (PDT) (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 w862hq7o058504; Wed, 5 Sep 2018 19:43:52 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201809060243.w862hq7o058504@pdx.rh.CN85.dnsmgr.net> Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap) In-Reply-To: <20180906003829.GC818@www.zefox.net> To: bob prohaska Date: Wed, 5 Sep 2018 19:43:52 -0700 (PDT) CC: 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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 02:43:56 -0000 > On Sat, Sep 01, 2018 at 04:02:33PM -0700, bob prohaska wrote: > > > > With r338342 and > > vm.pageout_oom_seq="1024" > > in /boot/loader.conf the RPI3 is a bit closer to a Mars Rover. > > No panics, crashes or USB errors, -j4 buildworld runs to completion. > > When swap usage goes over about 50% the system slows, but doesn't give up. > > There are six 1 GB swap partitions available, 3 on USB and 3 on microSD. > > > > Log files are at > > http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/ > > for the combinations tried so far. > > > > It looks as if using all six GB of swap doesn't cause any immediate problem, > at least so long as swap usage stays relatively low, say 1.5 GB. In a final > test, TRIM was turned on without catastrophe, though it had little to do > given that all the busy filesystems were on USB. The penalty was about one > hour extra (25 vs 24 hours) to run -j4 buildworld from a clean start. > > One chance observation caught my attention, however. I'd always thought > the VM system would favor fast swap devices over slow, but the gstat log > recorded this, visible at > http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/3gbsd_3gbusb/trim_on/swapscript.log What makes you believe that the VM system has any concept about the speed of swap devices? IIRC it simply uses them in a round robbin fashion with no knowlege of them being fast or slow, or shared with files systems or other stuff. > dT: 10.004s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name > 3 175 91 673 4.0 84 701 4.0 0 0 0.0 24.4 mmcsd0 > 4 173 88 693 106.6 86 723 176.5 0 0 0.0 103.4 da0 > 1 58 30 224 4.5 28 220 4.1 0 0 0.0 14.5 mmcsd0s2b > 3 175 91 673 4.0 84 701 4.0 0 0 0.0 24.7 mmcsd0s2 > 1 58 30 223 4.0 28 244 3.8 0 0 0.0 14.0 mmcsd0s2d > 1 59 31 227 3.7 28 237 4.3 0 0 0.0 14.9 mmcsd0s2e > 2 57 28 235 140.2 28 236 103.8 0 0 0.0 186.1 da0a > 0 56 28 224 178.4 28 222 35.9 0 0 0.0 131.5 da0b > 2 59 31 234 9.4 28 240 59.1 0 0 0.0 99.5 da0d > 0 0 0 0 0.0 0 3 15011 0 0 0.0 150.1 da0e > 0 1 0 0 0.0 1 22 13376 0 0 0.0 147.8 da0g > Tue Sep 4 15:07:39 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 236872 811704 23% > /dev/mmcsd0s2b 1048576 221568 827008 21% > /dev/da0d 1048576 218636 829940 21% > /dev/da0a 1048576 222028 826548 21% > /dev/mmcsd0s2d 1048576 221660 826916 21% > /dev/mmcsd0s2e 1048576 221392 827184 21% > Total 6291456 1342156 4949300 21% > Sep 4 14:57:52 www sshd[41673]: error: Received disconnect from 103.207.39.197 port 64499:3: com.jcraft.jsch.JSchException: Auth cancel [preauth] > Sep 4 15:04:19 www kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2217840, size: 12288 > > The system has lots of fast swap available on microSD, but is seemingly choking > trying to use the slow swap on da0 _and_ run traffic to /usr and /var. Buildworld > doesn't run any faster with less swap, so I don't think the oversupply is the problem. > > Is this expected behavior? I believe so, if da0 is a slow device to swap to it should probably not be used for swap. Unless things have drastically changed there are no priorites, speed, or load concerns about other stuff on the same device being considered by the VM system. > Thanks for reading, > bob prohaska -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Thu Sep 6 04:23:58 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45CB8FE6F94 for ; Thu, 6 Sep 2018 04:23:58 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 B74528472D for ; Thu, 6 Sep 2018 04:23:57 +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 w864NsgZ003887 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Sep 2018 21:23:55 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w864Nrpu003886; Wed, 5 Sep 2018 21:23:53 -0700 (PDT) (envelope-from fbsd) Date: Wed, 5 Sep 2018 21:23:53 -0700 From: bob prohaska To: "Rodney W. Grimes" Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap) Message-ID: <20180906042353.GA3482@www.zefox.net> References: <20180906003829.GC818@www.zefox.net> <201809060243.w862hq7o058504@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201809060243.w862hq7o058504@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 04:23:58 -0000 On Wed, Sep 05, 2018 at 07:43:52PM -0700, Rodney W. Grimes wrote: > > What makes you believe that the VM system has any concept about > the speed of swap devices? IIRC it simply uses them in a round > robbin fashion with no knowlege of them being fast or slow, or > shared with files systems or other stuff. > Mostly the assertion that OOMA kills happening when the system had plenty of free swap were caused by the swap being "too slow". If the machine knows some swap is slow, it seems capable of discerning other swap is faster. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Thu Sep 6 05:15:25 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A9F8FE8115 for ; Thu, 6 Sep 2018 05:15:25 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 5C41685C8D for ; Thu, 6 Sep 2018 05:15:24 +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 w865FL5t004021 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Sep 2018 22:15:22 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w865FKNV004020; Wed, 5 Sep 2018 22:15:21 -0700 (PDT) (envelope-from fbsd) Date: Wed, 5 Sep 2018 22:15:20 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap) Message-ID: <20180906051520.GB3482@www.zefox.net> References: <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <20180906003829.GC818@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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 05:15:25 -0000 On Wed, Sep 05, 2018 at 07:05:11PM -0700, Mark Millard wrote: > [I've omitted Kirk McKusick as my notes are largely off subject for > what he asked about for testing specific to his changes.] > > On 2018-Sep-5, at 5:38 PM, bob prohaska wrote: > > > On Sat, Sep 01, 2018 at 04:02:33PM -0700, bob prohaska wrote: > > > > It looks as if using all six GB of swap doesn't cause any immediate problem, > > at least so long as swap usage stays relatively low, say 1.5 GB. In a final > > test, TRIM was turned on without catastrophe, though it had little to do > > given that all the busy filesystems were on USB. The penalty was about one > > hour extra (25 vs 24 hours) to run -j4 buildworld from a clean start. > > What UFS file systems with TRIM enabled were on some /dev/mmcsd0* ? Everything _except_ /var, /tmp and /usr. Effectively, not much. > Did you 1st use "fsck_ffs -E" on any of the file systems where > trim would work? No, I did not. > > If I gather right, the "clean start" was on USB where TRIM during the > clean would not be available. > By "clean start" I meant running make cleandir twice and removing /usr/obj/usr/src. That was done to make all of the -j4 buildworld tests consistent. > The extra swap space may have contributed to the extra time? Having > more swap uses more kernel memory for keeping track of the swap > if I understand right. That leaves less for other things. That could > have consequences other than outright failure. > There were two buildworld tests run with 6 GB of swap, the first without TRIM being turned on and the second with TRIM turned on. The second run too an hour longer, with TRIM being on the only difference. > Quoting "man 8 loader" related to kern.maxswzone : > > Note that swap metadata can be fragmented, which means that > the system can run out of space before it reaches the > theoretical limit. Therefore, care should be taken to not > configure more swap than approximately half of the > theoretical maximum. > > Running out of space for swap metadata can leave the system > in an unrecoverable state. > > This wording suggests not allocating 6 GiBytes of swap when 3.5 GiBytes > is approximately half the theoretical maximum --even if the system does > still operate with 6 GiBytes. > It's understood that 6 GB of swap on a Pi3 isn't a good idea. It was tried to see if something useful might be revealed. > (Note: The man page's reference to "eight times the amount of physical memory" > and such does not seem to apply to all platforms. And rpi2 V1.1 and an rpi3 > with the same amount of RAM get rather difference recommended figures > according to the messages generated.) > > > One chance observation caught my attention, however. I'd always thought > > the VM system would favor fast swap devices over slow, but the gstat log > > recorded this, visible at > > http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/3gbsd_3gbusb/trim_on/swapscript.log > > > > > > > > dT: 10.004s w: 10.000s > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name > > 3 175 91 673 4.0 84 701 4.0 0 0 0.0 24.4 mmcsd0 > > 4 173 88 693 106.6 86 723 176.5 0 0 0.0 103.4 da0 > > 1 58 30 224 4.5 28 220 4.1 0 0 0.0 14.5 mmcsd0s2b > > 3 175 91 673 4.0 84 701 4.0 0 0 0.0 24.7 mmcsd0s2 > > 1 58 30 223 4.0 28 244 3.8 0 0 0.0 14.0 mmcsd0s2d > > 1 59 31 227 3.7 28 237 4.3 0 0 0.0 14.9 mmcsd0s2e > > 2 57 28 235 140.2 28 236 103.8 0 0 0.0 186.1 da0a > > 0 56 28 224 178.4 28 222 35.9 0 0 0.0 131.5 da0b > > 2 59 31 234 9.4 28 240 59.1 0 0 0.0 99.5 da0d > > 0 0 0 0 0.0 0 3 15011 0 0 0.0 150.1 da0e > > 0 1 0 0 0.0 1 22 13376 0 0 0.0 147.8 da0g > > Are there any examples of "d/s kBps ms/d" being non-zero? If they are > always zero then no TRIMing likely happened. That in turn would make > TRIM an unlikely use of an extra hour. > Near as I can tell there are no non-zero values for d/s, which if it's tied to TRIM is reasonable for all but microSD, which did have TRIM enabled. Since microSD wasn't particularly busy, apart from swap, that too is unsurprising. > > Tue Sep 4 15:07:39 PDT 2018 > > Device 1K-blocks Used Avail Capacity > > /dev/da0b 1048576 236872 811704 23% > > /dev/mmcsd0s2b 1048576 221568 827008 21% > > /dev/da0d 1048576 218636 829940 21% > > /dev/da0a 1048576 222028 826548 21% > > /dev/mmcsd0s2d 1048576 221660 826916 21% > > /dev/mmcsd0s2e 1048576 221392 827184 21% > > Total 6291456 1342156 4949300 21% > > As I understand the normal use of multiple swap partitions > is to split the load across channels that can operate > independently in parallel. Having 3 such partitions on > the same channel/device may only add overhead vs. one > full-size partition per channel/device. > The multiple partitions on one device were a simple way to vary swap amounts. I did expect that having swap on both microSD and USB would lead to some performance gain, but it seems not so. > I also do not know if mmcsd0 and da0 can have independent, > parallel I/O activity in the rpi3 context. > That is a key point; I took it for granted that they _can_ have independent, parallel I/O activity. If not, seemingly it makes better sense, both for performance and cost, to use a single large microSD card and skip USB devices entirely. That seems to be where the evidence is leading me. > > Sep 4 14:57:52 www sshd[41673]: error: Received disconnect from 103.207.39.197 port 64499:3: com.jcraft.jsch.JSchException: Auth cancel [preauth] > > Sep 4 15:04:19 www kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2217840, size: 12288 > > Note: my context is very different from yours and I get no console > messages about I/O or waits during buildworld buildkernel or other > such build/install tests. > That's likely the benefit of having 2 GB of RAM, I would think. > > The system has lots of fast swap available on microSD, but is seemingly choking > > trying to use the slow swap on da0 _and_ run traffic to /usr and /var. Buildworld > > doesn't run any faster with less swap, so I don't think the oversupply is the problem. > > If I understand right, your only 6 GiByte swap experiment was slower > but you attributed all time variations to an (inactive? ever used?) > TRIM enabled status. You might want to manipulate the two > separately. For all I know something else may also have contributed. > The tests were 6 GB swap, TRIM off vs TRIM on. TRIM on took an extra hour, everything else kept the same to the best of my ability. I did the TRIM test sort of on a whim, just to see if things would go spectacularly wrong. That they didn't is encouraging. It certainly isn't decisive. > I've no clue if having so many swap partitions on the same channel/device > has consequences that having only one per channel/device would avoid. > > > Is this expected behavior? > > As I understand the approximately even split across the in-use swap > partitions is the normal way things are split. It is the placement > of the partitions themselves that contributes to how effective that > split is at improving the swap/paging I/O if I understand right. > The great difference in activity between da0 and mmcsd0 suggests they do have a degree of independence. Whether that independence can be exploited to improve swap throughput is the point I wanted to explore. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Thu Sep 6 06:20:23 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED67DFED33E for ; Thu, 6 Sep 2018 06:20:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-23.consmr.mail.gq1.yahoo.com (sonic312-23.consmr.mail.gq1.yahoo.com [98.137.69.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 74550881BA for ; Thu, 6 Sep 2018 06:20:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: W8a9A2EVM1kqzeygRzyeASmlrYYSpy.2vE5H.MqeuuN_NJTPIMXLLd_s5.ycjSV 94C0ttNMhjp_Mz9h5l3KEkd9Gh5BzaMdnqBUfI5bhxp14CE9mGp4nRoAHwblcrXowDl4ZgjnuHiF REw_cprjYManoHB9rqQ8ImM5AXGoteEruEzWgF438FL_BxSBtJOngPTvNjjcElvHcfK8CeWAtO38 WEI_atzq5LHioaNjL3_Rj.9vMFFI72zC9VCdoZKWnPhyWWRpwoCww2EUnKYndBGeXUJppJWArHBQ y7O2kSNekncGBqtX1E1pZS2LyCJrSGSpr.G41m3yujGcRq57PxF4EAIllY4raeUq6nHYZlmWj6FI XRYQyWF5zO2sGyZ2Uik7IiwF.E7a.m.SEEZZEHB9uPssnMz6eGX_oy6owkvk6r2sV7apiPRgPIUQ 5F2q_pLcSIHY3VGRtabkgx4aPgy_s23Y5rJiUcdzNhLa581iiuPkhjBHvmpANVczGT7e.GdTTR1M jprn1O5aRVJMY.ztR8CBFv3O1xbA4NIN9LKdrFNCOQ.TZJ_ntAaRaY27ES.1EEh33tpXVXg880bG 6KoJUkvri62BJvqb5IbZliuRriZOkUcWV_GsPCrC.VfsDxVkbhL45uX6WAb.NM5ThZER3.ry5pcV Ea3HiRfHqbPVUBwVAEFzEgWsZZ7ZIMfIUaZqXYOyekpzWjtGxz5qWxl6A9M9arCTY3QmKaOFnXXt 2T0S8nZSCib5vbGC85jjPgNwN7C_5YH0qqZI7dtmPYeTiDdASNiZ2XcGM1gJ1HegsqCUt.xnq7rK zvpIwF1Fz2Zm0zUyXoyaQQgjy65AwbWt4ya4Eh50rrmtYPwY3u1emd0kS5rtiw7iimvOupUJdo.J y0sbAKxOVr44XbEOohx_pMVez5fx5kl9QjQfYKC1nlKp8BnqATlnCarwcN6xLiGAfIdt0NrBlO2U q.IfP6iMV8dj_Tepxxj_0agPA6mzjyBsEqbOxgIcF6XaXOV0xrKFSz.5aydZUDHeqDhEJ0o2XpXD e1hz7S_n5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Thu, 6 Sep 2018 06:20:20 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp411.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 43b8988f7b1a700bb41dfb1de32c48da; Thu, 06 Sep 2018 06:20:16 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap) From: Mark Millard In-Reply-To: <20180906042353.GA3482@www.zefox.net> Date: Wed, 5 Sep 2018 23:20:14 -0700 Cc: "Rodney W. Grimes" , freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <20180906003829.GC818@www.zefox.net> <201809060243.w862hq7o058504@pdx.rh.CN85.dnsmgr.net> <20180906042353.GA3482@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 06:20:23 -0000 On 2018-Sep-5, at 9:23 PM, bob prohaska wrote: > On Wed, Sep 05, 2018 at 07:43:52PM -0700, Rodney W. Grimes wrote: >> >> What makes you believe that the VM system has any concept about >> the speed of swap devices? IIRC it simply uses them in a round >> robbin fashion with no knowlege of them being fast or slow, or >> shared with files systems or other stuff. >> > > Mostly the assertion that OOMA kills happening when the system had > plenty of free swap were caused by the swap being "too slow". If the > machine knows some swap is slow, it seems capable of discerning other > swap is faster. If an RPI3 magically had a full-speed/low-latency optane context as its swap space, it would still get process kills for buildworld buildkernel for vm.pageout_oom_seq=12 for -j4 as I understand things at this point. (Presumes still having 1 GiByte of RAM.) In other words: the long latency issues you have in your rpi3 configuration may contribute to the detailed "just when did it fail" but low-latency/high-speed I/O would be unlikely to prevent kills from eventually happening during the llvm parts of buildworld . Free RAM would still be low for "long periods". Increasing vm.pageout_oom_seq is essential from what I can tell. vm.pageout_oom_seq is about controlling "how long". -j1 builds are about keeping less RAM active. (That is also the intent for use of LDFLAGS.lld+=-Wl,--no-threads .) Of course, for the workload involved, using a context with more RAM can avoid having "low RAM" for as long. An aarch64 board with 4 GiBYte of RAM and 4 cores possibly has no problem for -j4 buildworld buildkernel for head at this point: Free RAM might well never be low during such a build in such a context. (The quotes like "how long" are because I refer to the time consequences, the units are not time but I'm avoiding the detail.) The killing criteria do not directly measure and test swapping I/O latencies or other such as far as I know. Such things are only involved indirectly via other consequences of the delays involved (when they are involved at all). That is my understanding. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Sep 6 07:08:16 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F35B8FF130E for ; Thu, 6 Sep 2018 07:08:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-21.consmr.mail.ne1.yahoo.com (sonic311-21.consmr.mail.ne1.yahoo.com [66.163.188.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8DDE789F9A for ; Thu, 6 Sep 2018 07:08:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: cWfHNJUVM1lW7_uExuNQ2xedxnEBxLRYRUa._fjD04LKLNtNItYq5D0edPaucyS XJVWUTE8vGJTb5ehubQ_A5fzfD1y96xiMu_mMdw27fHzScsldJw4oaihbjDm76uysE3oJg8CzGMp bMK.1FonCLCcPytRZgp8zv96OtZXvUrr8Nv_xRcJj.kTi3Lbv7lU7JgbRw7MnJs93DBptDi.l5Hx 4w.JW0EVYn3EjjuZwNKIEsOUgAaKJ7Dc1lOwJbHdJHDzLweJR2QKupiiZxcMOoTFqZyI9KtHr2XN RI3k2CvKq.n8yl.CFpb7oCUmf_Q3SpkVvn7kfHgqZPGEcxEIIFKc7_j.xXUo4XBfzZ7OwxPwaOf3 hfR9fZCe4.74WC5jQf5VlQ8zek8aMvPM0DoSgVFbqWgpzhWXHxHhw0zuxTrOjr_BqOfeBrXxR7mE BKVFtgpNdp6IsrkQfTYRU7Jb5K..P1ZqDzNCNfbAsVr76bqSS2_nTSJ.WnIBA_4nFgFikyp_jS_t rtnx0kmYNG9FJ2H_RONdc1J.0_Mb9DJ2oMURJt2_U5hal3SeKqH5v5xCASbYDXg1qrehKYSk6m4Y rIa1SGd8d.n3xKtrkzNtIrtxdgoEpsloRZGXZFUBd.UT3OdpHLubYQRDOOc0gEaEoDBnLyAlztSz hzmXX_wf__B5ypTtT4y7uo1iJGNPc_cmu.NUeK4xbYT9EMiZWA9025KQ9fg6wtPlh6JZP7VFkhIf 9RSXE4jWnM4cQXgZiEHmzavRpghYNXU59Oa7NPOtvg3y_O1vw1J_eREUlJy5SqhcGqmB1F1clLP6 yF.2jpANwTSbWM1Pufg7wpA3SCgfOzjolx95F42IhMg.tJ_aJDjg9RDILaDUzOm3qFamziBHRKrF enH4.U0FvlM4rYzrsCujz4MNheswSPLLwYJ.765CvwdaJOqEbwL9QauB451DKd_T_LhmPMS.ZO8a 1MEYhqk3_sBd1WCnMVn89NwDIdgYk_w9.8UQtKIdc8MJ_4KPk_KCKHlW4eOby6eqqYVhCkfZFP9i Bbd0q1OSBvWjC Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Thu, 6 Sep 2018 07:08:14 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp419.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 72ca2d19f362c25c7413e072fe5c6f1a; Thu, 06 Sep 2018 07:08:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap) From: Mark Millard In-Reply-To: <20180906051520.GB3482@www.zefox.net> Date: Thu, 6 Sep 2018 00:08:09 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <059D2FED-6E7C-4FEF-8807-8D4A0D0B3E26@yahoo.com> References: <20180813185350.GA47132@www.zefox.net> <20180814014226.GA50013@www.zefox.net> <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <20180906003829.GC818@www.zefox.net> <20180906051520.GB3482@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 07:08:16 -0000 On 2018-Sep-5, at 10:15 PM, bob prohaska wrote: >> . . . > There were two buildworld tests run with 6 GB of swap, the first = without > TRIM being turned on and the second with TRIM turned on. The second = run > too an hour longer, with TRIM being on the only difference.=20 buildworld did not take an hour longer for one vs. the other based on the timestamps in the log files: trim off: >>> World build started on Sun Sep 2 20:28:12 PDT 2018 . . . >>> World build completed on Mon Sep 3 21:35:47 PDT 2018 So somewhat over 25 hours 7 minutes. trim on: >>> World build started on Tue Sep 4 00:02:36 PDT 2018 . . . >>> World build completed on Wed Sep 5 01:12:47 PDT 2018 So somewhat over 25 hours 10 minutes. I get an under 5 minute difference from those timestamps. >> . . . > Near as I can tell there are no non-zero values for d/s, which if it's = tied > to TRIM is reasonable for all but microSD, which did have TRIM = enabled. Since > microSD wasn't particularly busy, apart from swap, that too is = unsurprising. = http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/3gbsd_3gbusb/trim_on/wri= tedelay.sort shows ms/d and its matching kBps with the below non-zero figures: . . . 0 0 0 0 0.0 0 6 16.2 0 10 = 0.1 0.3 mmcsd0 0 0 0 0 0.0 0 6 16.3 0 10 = 0.2 0.3 mmcsd0s2 . . . 0 0 0 0 0.0 0 3 99.2 0 4 = 40.7 1.3 mmcsd0s2a 0 0 0 0 0.0 0 3 99.3 0 4 = 40.8 1.3 ufs/rootfs . . . 0 0 0 0 0.0 0 10 147.6 0 6 = 12.0 4.5 mmcsd0s2a . . . 0 2 1 8 1.8 0 7 211.0 0 10 = 114.5 5.8 mmcsd0 0 2 1 8 1.8 0 7 211.1 0 10 = 114.5 5.8 mmcsd0s2 0 1 0 0 0.0 0 7 211.2 0 10 = 114.6 5.6 ufs/rootfs . . . Those are all I found. I may have missed some. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Sep 6 07:08:16 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0749FF1314 for ; Thu, 6 Sep 2018 07:08:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6769C89F9D for ; Thu, 6 Sep 2018 07:08:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 2CD64FF1310; Thu, 6 Sep 2018 07:08:16 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BB02FF130F for ; Thu, 6 Sep 2018 07:08:16 +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 A8A0289F9B for ; Thu, 6 Sep 2018 07:08:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1fxoOY-0006kA-KU for arm@freebsd.org; Thu, 06 Sep 2018 10:08:02 +0300 From: Daniel Braniss Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: nanopi/allwinner h3/h5/a64 and if_awg blues Message-Id: Date: Thu, 6 Sep 2018 10:08:02 +0300 To: "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 07:08:16 -0000 Hi, as far as I can tell, all these platforms share the same driver, but not = the same dts in any case this is the current status: on h3: only detected/works if cable is connected on h5: is detected even without cable and works after cable is = inserted. Note: to get it working had to add sun50i-h5-neo2.dts to = modules/dtb/allwinner/Makefile on a64: nothing, nada. so, any idea as to how to get it working on an sun50i-a64 (nanopi-a64)?=20= BTW, I did get the wireless to work! cheers, danny From owner-freebsd-arm@freebsd.org Thu Sep 6 07:08:33 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57A09FF136E for ; Thu, 6 Sep 2018 07:08:33 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 CD97C89FF5 for ; Thu, 6 Sep 2018 07:08:32 +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 w8678Tlu004340 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Sep 2018 00:08:30 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w8678SeJ004339; Thu, 6 Sep 2018 00:08:28 -0700 (PDT) (envelope-from fbsd) Date: Thu, 6 Sep 2018 00:08:28 -0700 From: bob prohaska To: Mark Millard Cc: "Rodney W. Grimes" , freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap) Message-ID: <20180906070828.GC3482@www.zefox.net> References: <20180906003829.GC818@www.zefox.net> <201809060243.w862hq7o058504@pdx.rh.CN85.dnsmgr.net> <20180906042353.GA3482@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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 07:08:33 -0000 On Wed, Sep 05, 2018 at 11:20:14PM -0700, Mark Millard wrote: > > > On 2018-Sep-5, at 9:23 PM, bob prohaska wrote: > > > On Wed, Sep 05, 2018 at 07:43:52PM -0700, Rodney W. Grimes wrote: > >> > >> What makes you believe that the VM system has any concept about > >> the speed of swap devices? IIRC it simply uses them in a round > >> robbin fashion with no knowlege of them being fast or slow, or > >> shared with files systems or other stuff. > >> > > > > Mostly the assertion that OOMA kills happening when the system had > > plenty of free swap were caused by the swap being "too slow". If the > > machine knows some swap is slow, it seems capable of discerning other > > swap is faster. > > If an RPI3 magically had a full-speed/low-latency optane context > as its swap space, it would still get process kills for buildworld > buildkernel for vm.pageout_oom_seq=12 for -j4 as I understand > things at this point. (Presumes still having 1 GiByte of RAM.) > > In other words: the long latency issues you have in your rpi3 > configuration may contribute to the detailed "just when did it > fail" but low-latency/high-speed I/O would be unlikely to prevent > kills from eventually happening during the llvm parts of buildworld . > Free RAM would still be low for "long periods". Increasing > vm.pageout_oom_seq is essential from what I can tell. > Understood and accepted. I'm using vm.pageout_oom_seq=1024 at present. The system struggles mightily, but it keeps going and finishes. > vm.pageout_oom_seq is about controlling "how long". -j1 builds are > about keeping less RAM active. (That is also the intent for use of > LDFLAGS.lld+=-Wl,--no-threads .) Of course, for the workload involved, > using a context with more RAM can avoid having "low RAM" for > as long. An aarch64 board with 4 GiBYte of RAM and 4 cores possibly > has no problem for -j4 buildworld buildkernel for head at this > point: Free RAM might well never be low during such a build in such > a context. > > (The quotes like "how long" are because I refer to the time > consequences, the units are not time but I'm avoiding the detail.) > > The killing criteria do not directly measure and test swapping I/O > latencies or other such as far as I know. Such things are only > involved indirectly via other consequences of the delays involved > (when they are involved at all). That is my understanding. > Perhaps I'm being naive here, but when one sees two devices holding swap, one at ~25% busy and one at ~150% busy, it seems to beg for a little selective pressure for diverting traffic to the less busy device from the more busy one. Maybe it's impossible, maybe it's more trouble than the VM folks want to invest. Just maybe, it's doable and worthwhile, to take advantage of a cheap, power efficient platform. I too am unsure of the metric for "too slow". From earlier discussion I got the impression it was something like a count of how many cycles of request and rejection (more likely, deferral) for swap space were made; after a certain count is reached, OOMA is invoked. That picture is sure to be simplistic, and may well be flat-out wrong. If my picture is not wholly incorrect, it isn't a huge leap to ask for swap device-by-device, and accept swap from the device that offers it first. In the da0 vs mmcsd0 case, ask for swap on each in turn, first to say yes gets the business. The busier one will will get beaten in the race by the more idle device, relieving the bottleneck to the extent of the faster device's capacity. It isn't perfect, but it's an improvement. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Thu Sep 6 08:04:49 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46D02FF2E50 for ; Thu, 6 Sep 2018 08:04:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C58E38BF1A for ; Thu, 6 Sep 2018 08:04:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: MVKxjuIVM1ndo3VVqTY666UY98MifbuVumWaHWse33x7fb.yLc6XHj1EvZ78nQq .84fTow3GPYn0KeykyFrmGg8AGxoigWKTCXmUq1X97oXU.HKVTETunp6BqwzINOv5ABaL5VJyTTo 7TI96OZpqevvha9pgSO8Gn6YsE9P.thzMOEKf2TAbtji3Lla4SVEmOYTeU2VkkIH3cNoU1tpi2mU fCdlanBeRfUQ1_LmW_8.pH0Zw2OBz7Rup1fahWdIs0YCFgiqDe_l26V4LBUXLFCNLlmPUsdP3wYu Un5.xzUljoxrCfyV9IrSJNX0LnF7N5o2nAsanA5GNZwFTlCSYMC4oostMnDZb6PdyLAgLE0LcAjO uEVTh9e0yAqgD6E98mTtGXMwl13vaAdUVmWIJXimnunk2K0ZmVV5AGO0R.tC1yaxjFQHfBu.kQlK Jx2DfH4fP_XZKX6dbPNDDCWb6e15Gzg.r4NK14iItPy44GvG2mZKsBGOH55C7oY2IadtqgikeH1D qXfxJ69XGl7b9E2W9eT4xV11RLrWlEvWd5AunW3Zwqy0K8CFO2ztnAnvL1GzgMJt.Wi3fsrCWKng p1abL8sYAqc75g19CIrDCaxAMt5TPyCZCqTmkrDiTUyD4YwrFH0tvqp02LCAZ80Z9teEWS9W6RWy pe7H9JCIROUfHomXUZKiccRGf2miR8sQMPHuC1O1s1XPlotBTsiF4vjCbKmXHy0mNtYtTrOZU4xd 4rxsfExua6ic0Lz6Zf6840y1AC5yCjS7b8kjtpzkzRIohP.SkQlw4fWNJoLeZjTydWnJaZ0JZIjS pRFaOSHfVuO83JmEWdjXJQ27Crkr8XunqfHLJB_YisOJiEOawxaREBu4ozxvxAlnkdN.OKyKQeIQ 20WbOnl6VfsYHcjbEHICHeUo4pFslRo5G7Joz8p.jwreo5sMDU1cqVPSuKsK0okBkRbcykF4sJzA K7CZWVPDw..G_HU38CCxXg9xt8_UB2S4kP_2LRivP4Mh3pNtTu4tJt6YtlC7apgmUHKn8EceDh_r XZ9Na_.iI Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 6 Sep 2018 08:04:42 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp431.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 51ddb76204aa819a1b0fca688b2eb7ef; Thu, 06 Sep 2018 08:04:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap) From: Mark Millard In-Reply-To: <20180906070828.GC3482@www.zefox.net> Date: Thu, 6 Sep 2018 01:04:37 -0700 Cc: "Rodney W. Grimes" , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180906003829.GC818@www.zefox.net> <201809060243.w862hq7o058504@pdx.rh.CN85.dnsmgr.net> <20180906042353.GA3482@www.zefox.net> <20180906070828.GC3482@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 08:04:49 -0000 On 2018-Sep-6, at 12:08 AM, bob prohaska wrote: > On Wed, Sep 05, 2018 at 11:20:14PM -0700, Mark Millard wrote: >>=20 >>=20 >> On 2018-Sep-5, at 9:23 PM, bob prohaska = wrote: >>=20 >>> On Wed, Sep 05, 2018 at 07:43:52PM -0700, Rodney W. Grimes wrote: >>>>=20 >>>> What makes you believe that the VM system has any concept about >>>> the speed of swap devices? IIRC it simply uses them in a round >>>> robbin fashion with no knowlege of them being fast or slow, or >>>> shared with files systems or other stuff. >>>>=20 >>>=20 >>> Mostly the assertion that OOMA kills happening when the system had >>> plenty of free swap were caused by the swap being "too slow". If the >>> machine knows some swap is slow, it seems capable of discerning = other >>> swap is faster.=20 >>=20 >> If an RPI3 magically had a full-speed/low-latency optane context >> as its swap space, it would still get process kills for buildworld >> buildkernel for vm.pageout_oom_seq=3D12 for -j4 as I understand >> things at this point. (Presumes still having 1 GiByte of RAM.) >>=20 >> In other words: the long latency issues you have in your rpi3 >> configuration may contribute to the detailed "just when did it >> fail" but low-latency/high-speed I/O would be unlikely to prevent >> kills from eventually happening during the llvm parts of buildworld . >> Free RAM would still be low for "long periods". Increasing >> vm.pageout_oom_seq is essential from what I can tell. >>=20 > Understood and accepted. I'm using vm.pageout_oom_seq=3D1024 at = present. > The system struggles mightily, but it keeps going and finishes. >=20 >> vm.pageout_oom_seq is about controlling "how long". -j1 builds are >> about keeping less RAM active. (That is also the intent for use of >> LDFLAGS.lld+=3D-Wl,--no-threads .) Of course, for the workload = involved, >> using a context with more RAM can avoid having "low RAM" for >> as long. An aarch64 board with 4 GiBYte of RAM and 4 cores possibly >> has no problem for -j4 buildworld buildkernel for head at this >> point: Free RAM might well never be low during such a build in such >> a context. >>=20 >> (The quotes like "how long" are because I refer to the time >> consequences, the units are not time but I'm avoiding the detail.) >>=20 >> The killing criteria do not directly measure and test swapping I/O >> latencies or other such as far as I know. Such things are only >> involved indirectly via other consequences of the delays involved >> (when they are involved at all). That is my understanding. >>=20 > Perhaps I'm being naive here, but when one sees two devices holding > swap, one at ~25% busy and one at ~150% busy, it seems to beg for > a little selective pressure for diverting traffic to the less busy > device from the more busy one. Maybe it's impossible, maybe it's more > trouble than the VM folks want to invest. Just maybe, it's doable > and worthwhile, to take advantage of a cheap, power efficient = platform. Continuously reorganize were things page out to in the swap partitions on the fly? (The reads have to be from where it was paged out.) What virtual memory pages will be written out and read in and how often is not known up front and is not predicable and varies over time. That some partitions end up with more active paging than others is not all that surprising. Avoiding such would have overhead that was always involved --and would use even more RAM for the extra tracking. It would also involve trying to react as fast as the demand changes: the full speed of the programs that are keeping "cores" and RAM in active use. > I too am unsure of the metric for "too slow". =46rom earlier = discussion > I got the impression it was something like a count of how many cycles > of request and rejection (more likely, deferral) for swap space were > made; after a certain count is reached, OOMA is invoked. That picture > is sure to be simplistic, and may well be flat-out wrong. Note that writing out a now-dirty RAM page that was already written out before need not allocate any new swap space: reuse the place it used before. But if the RAM page is in active enough use, writing it out and freeing the page could just lead to it being read back in (allocating a free RAM page nearly immediately). Such can be viewed be a waste of time. Another wording for this is something like "the system working set" can be so large that paging becomes ineffective (performs too poorly). Having virtual memory "thrashing" can slow things by orders of magnitude. It has more to do with something like counting attempts at moving dirty RAM pages out that have not been used as recently in order to hopefully free the RAM pages written out. (But the RAM pages may become active again before they are freed.) Clean RAM pages can more directly be freed but there is still an issue of such a page being in active use to the point that freeing it would just lead to reading it back in to a newly allocated RAM page. The handling of this need not use up all the swap space before not making progress at freeing RAM and so not keeping a sufficient amount of it free. Thrashing does not require the swap space all be used. There might be no swap space set up at all. (I've done this on a 128 GiByte RAM configuration.) "OOM" kills still can happen: dirty pages and clean pages have no place to be written out to in order to increase free memory. If free RAM gets low, OOM kills start. > If my picture is not wholly incorrect, it isn't a huge leap to ask for > swap device-by-device, and accept swap from the device that offers it = first. > In the da0 vs mmcsd0 case, ask for swap on each in turn, first to say = yes gets > the business. The busier one will will get beaten in the race by the = more > idle device, relieving the bottleneck to the extent of the faster = device's > capacity. It isn't perfect, but it's an improvement. See my comments above about needing to reorganizes where the RAM pages go in the swap partitions on the fly over time. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Sep 6 08:15:12 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6344FF32B7 for ; Thu, 6 Sep 2018 08:15:12 +0000 (UTC) (envelope-from zrahimkhani2014@gmail.com) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36CE68C4F1 for ; Thu, 6 Sep 2018 08:15:12 +0000 (UTC) (envelope-from zrahimkhani2014@gmail.com) Received: by mail-lj1-x233.google.com with SMTP id y17-v6so8536713ljy.8 for ; Thu, 06 Sep 2018 01:15:12 -0700 (PDT) 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=+zozc3xazDuVykvgcUsaOqho9WlvmYC2LUzwlkRZ0dY=; b=koLKY7KsT3EPDTrrour3tZsKp/PG9+vuqu/xqHjBrMydiSw8AmLiT5dlzgazihjBFu sbZyEl1uG7rj4CTr+oeiIE36Jx6iqrO880DxZlaWCVdwbL3gzwkn182Wi2Ue/G6j/CjV YC+MFT4Np8jNCPxgnsmO9CmktSjcvWqGSdb9NK6qFkz6SBIBPsVBS8HE7fPaXEwdlgW0 hGhdEb7qH0O6V5XaA+KbmmM1JxNh/kQGuFgudtiNcUuhubK9NsWZ0PYAZF1rJgzNIdiI lGgurf9QavuDURRDD3f+7sIZXdNyt10WXuK6zo2x6O6nhBOeXp50Ud1cJVxUCnzSmgpB kNjw== 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=+zozc3xazDuVykvgcUsaOqho9WlvmYC2LUzwlkRZ0dY=; b=nqOeo7LrLZLX93zJ9hrkWJE9pdN2j00hY0vMJbnaeEkAK3eKtjPGlOfM/o9Bw69doO c2Ph0m5L76YANUScBkzEI0JiDVl+ANjCyLMipaB6VCojm5A0j+wAYWvANsVk+4hBvIth +GUZsVqe+MhO4QsgnTNKgpF286wuBdFiVBXqxkMy155sZw2P4/laHhFw14ko5CKrY8Ms AUaGjqeQ6VbODLK3Qh3KU/zkqSemYPA2mFV93qBntwHu2q3dj/ZDRhms7rrvJ2d7CHSu 3BUDR0VBrP7uG8hWMNdgBCws75Tl0qnzegEOf+hdhkEAd9a9KMLMu6I+FKPdrApBlQTl jc7g== X-Gm-Message-State: APzg51CCxX8G97zP8WzW8gzZjAw7gofb0scATu7mBKFElAqLfKkKC5Cb ggT675B4T4Y4016YBRG+R1KZS4MoYQuJVl12G/7yG5fMHIo= X-Google-Smtp-Source: ANB0VdY8rvwIEu+HWUUcI1YbMHoRWhbjWsVa3m1XD5KOf73WlCbQa1ioqLNTP9V7krxRlNE2q/3ZuJPgsAiv2n0xCzg= X-Received: by 2002:a2e:8103:: with SMTP id d3-v6mr1065477ljg.3.1536221710360; Thu, 06 Sep 2018 01:15:10 -0700 (PDT) MIME-Version: 1.0 From: zahra rahimkhani Date: Thu, 6 Sep 2018 12:45:00 -0300 Message-ID: Subject: problem with serial port To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 08:15:12 -0000 Hello I have this message when Freebsd loaded with sd ard by serial port . bcm2835-aux-uart 3f215040.serial: could not get clk: -517 Could you explain me how to solve it ? Thanks, Zahra From owner-freebsd-arm@freebsd.org Thu Sep 6 15:59:03 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 666F9FFF516 for ; Thu, 6 Sep 2018 15:59:03 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 C31037D709 for ; Thu, 6 Sep 2018 15:59:02 +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 w86Fwx6g006150 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Sep 2018 08:59:00 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w86FwxcN006149; Thu, 6 Sep 2018 08:58:59 -0700 (PDT) (envelope-from fbsd) Date: Thu, 6 Sep 2018 08:58:58 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap) Message-ID: <20180906155858.GA5980@www.zefox.net> References: <20180814014226.GA50013@www.zefox.net> <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <20180906003829.GC818@www.zefox.net> <20180906051520.GB3482@www.zefox.net> <059D2FED-6E7C-4FEF-8807-8D4A0D0B3E26@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <059D2FED-6E7C-4FEF-8807-8D4A0D0B3E26@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 15:59:03 -0000 On Thu, Sep 06, 2018 at 12:08:09AM -0700, Mark Millard wrote: > On 2018-Sep-5, at 10:15 PM, bob prohaska wrote: > > >> . . . > > There were two buildworld tests run with 6 GB of swap, the first without > > TRIM being turned on and the second with TRIM turned on. The second run > > too an hour longer, with TRIM being on the only difference. > > buildworld did not take an hour longer for one vs. the other > based on the timestamps in the log files: > > trim off: > > >>> World build started on Sun Sep 2 20:28:12 PDT 2018 > . . . > >>> World build completed on Mon Sep 3 21:35:47 PDT 2018 > > So somewhat over 25 hours 7 minutes. > > trim on: > > >>> World build started on Tue Sep 4 00:02:36 PDT 2018 > . . . > >>> World build completed on Wed Sep 5 01:12:47 PDT 2018 > > So somewhat over 25 hours 10 minutes. > > I get an under 5 minute difference from those timestamps. > > You are correct, the mistake is mine. Thanks for catching it! > >> . . . > > Near as I can tell there are no non-zero values for d/s, which if it's tied > > to TRIM is reasonable for all but microSD, which did have TRIM enabled. Since > > microSD wasn't particularly busy, apart from swap, that too is unsurprising. > > http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/3gbsd_3gbusb/trim_on/writedelay.sort > shows ms/d and its matching kBps with the below non-zero figures: > > . . . > 0 0 0 0 0.0 0 6 16.2 0 10 0.1 0.3 mmcsd0 > 0 0 0 0 0.0 0 6 16.3 0 10 0.2 0.3 mmcsd0s2 > . . . > 0 0 0 0 0.0 0 3 99.2 0 4 40.7 1.3 mmcsd0s2a > 0 0 0 0 0.0 0 3 99.3 0 4 40.8 1.3 ufs/rootfs > . . . > 0 0 0 0 0.0 0 10 147.6 0 6 12.0 4.5 mmcsd0s2a > . . . > 0 2 1 8 1.8 0 7 211.0 0 10 114.5 5.8 mmcsd0 > 0 2 1 8 1.8 0 7 211.1 0 10 114.5 5.8 mmcsd0s2 > 0 1 0 0 0.0 0 7 211.2 0 10 114.6 5.6 ufs/rootfs > . . . > > Those are all I found. I may have missed some. > Again, I was mistaken, misreading your original question. Thanks for catching the errors! bob prohaska From owner-freebsd-arm@freebsd.org Thu Sep 6 16:35:54 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3392FFCC3B0 for ; Thu, 6 Sep 2018 16:35:54 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B01D27F2B0 for ; Thu, 6 Sep 2018 16:35:53 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: by mailman.ysv.freebsd.org (Postfix) id 746F3FCC3AF; Thu, 6 Sep 2018 16:35:53 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52759FCC3AE for ; Thu, 6 Sep 2018 16:35:53 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E11897F2AB; Thu, 6 Sep 2018 16:35:49 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w86GZlf0042264 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Sep 2018 09:35:48 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w86GZlik042263; Thu, 6 Sep 2018 09:35:47 -0700 (PDT) (envelope-from jmg) Date: Thu, 6 Sep 2018 09:35:47 -0700 From: John-Mark Gurney To: arm@FreeBSD.org Subject: Allwinner awg TX hanging issue Message-ID: <20180906163547.GC75530@funkthat.com> Mail-Followup-To: arm@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Thu, 06 Sep 2018 09:35:48 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 16:35:54 -0000 Since I upgraded to a recent -current to fix the timer issue on my A64-LTS board, I've been having an issue where the ethernet interface will freeze. This is with: FreeBSD gate2.funkthat.com 12.0-ALPHA4 FreeBSD 12.0-ALPHA4 #4 r338426M: Wed Sep 5 09:55:12 PDT 2018 root@gate2.funkthat.com:/usr/src/sys/arm64/compile/GENERIC arm64 The modified code is simply to add some dtrace probe points to debug this issue. I also dropped the check for _OACTIVE from _start_locked. It prints flag at the begining of _start_locked and if _OACTIVE gets set and at the end of _txeof if progress was made. It also prints the progress at the end of txeof if any... It prints the val of _intr.. I noticed that when it was hung, the OACTIVE flag was set, but this just means that we ran out of transmit descriptors, and was a symptom of the problem. I don't have a good test to trigger this problem. This happens somewhat regularly, every 4-12 hours on my router, but my test board, which is lightly loaded and does not run pf doesn't have this issue. With the added dtrace probe points, I finally hit this: 3 10115 none:intr intr 40000024 3 10115 none:intr intr 40000100 3 10115 none:intr intr 40000100 3 10115 none:intr intr 40000100 3 10115 none:intr intr 40000100 3 10114 none:flags flag 40 3 10115 none:intr intr 40000024 3 10115 none:intr intr 40000100 3 10114 none:flags flag 40 3 10115 none:intr intr 40000024 3 10115 none:intr intr 40000100 3 10114 none:flags flag 40 3 10115 none:intr intr 40000024 3 10115 none:intr intr 40000100 3 10114 none:flags flag 40 3 10115 none:intr intr 40000100 3 10115 none:intr intr 40000024 3 10115 none:intr intr 4000010a 3 10114 none:flags flag 40 3 10115 none:intr intr 40000100 3 10114 none:flags flag 40 3 10115 none:intr intr 40000100 3 10114 none:flags flag 40 [...] 3 10115 none:intr intr 40000100 3 10114 none:flags flag 40 3 10114 none:flags flag 440 3 10115 none:intr intr 40000100 3 10115 none:intr intr 40000100 3 10115 none:intr intr 40000100 The intr 24 line is a normal interrupt, and will run txeof to free up descriptors. The intr 100 line is saying the RGMII link status changed, we don't enable it, so I'm not sure why we are getting these interrupts (it seems like the enable bit is ignored). These are normal, and see these lines for a long while. The flag 440 line is when we set OACTIVE, and then we see no more flag 40 lines, which means that _start_locked doesn't get called and that _txeof doesn't make forward progress. The problem point is the intr 10a line. Once we hit that line, we never get another intr 24 line. The a is the important part of the inter status, as it is: 0x8 TX_TIMEOUT_INT When this bit is asserted, the transmitter had been excessively active. and: 0x2 TX_DMA_STOPPED_INT When this bit is asserted, the TX DMA FSM is stopped. We do not have code in the awg driver to recover from this problem. Does anyone have any ideas? Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Thu Sep 6 17:33:03 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91B51FCDF12 for ; Thu, 6 Sep 2018 17:33:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-4.consmr.mail.bf2.yahoo.com (sonic301-4.consmr.mail.bf2.yahoo.com [74.6.129.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 38ECB81702 for ; Thu, 6 Sep 2018 17:33:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: _x.UZ_sVM1lY2q_qZmtzeCBpf91IvCqLpCPosjA6P_pkMBY7Bf_bURWGh15ktoW 2XRMXEW8bf7wz5wxNC1_JzXR3EKs0F2A2d0lg27nLvlyoXRK1OSn5ym.O0ic4vX574vVcXesfP27 YV3G9VC5Sx344ffcpNzWOIay6zO9ENR1PHRJS8eX.bNP.zbXK8LS2k31AdOUlLYdqVNgZbkmKCYV jEFnrspw1AmvxtQKUTnpdtAgaYeP7hKUckX77GC4qy2.yWeuIy0522Bo.nWVz6YRmf0BvZLQOnSm umLD_pSX4YhtiKb7pIdVtl2SquAtRdi7v96uF3oVBWzaSIPRulND71ROYyDFeVGFuS5nrF27oA95 GEXkSps11SEc_3CGQy9g9oG4bVQTlc1cUTAC3muYd5VpCt0vtbNVeqjRgiMDC27bXUgjV7f3qmmq 07BkVCiimN28Zm1YNvN5xd5hfHxZxLIk4vB3pFDDM8VtgMvw4oEoIQTIJP63hSLIRXF_TNv1fqBS rhDWv4IbDvpaZLdX9UmfByNIS.5ZbaZmpzUpgDu5lqbVuqGhAUoUM8QC7xjbenkBOs2fXwFtMm.g FjQOi4r.1635wiCM20LmlLCu6fNYqP8xKr0jSel.M64gGlfAacSr8AWzvo_i7zad5PjSVczVvxul 5JqYm7RiV.abNUSyfsgB9cW_5FFoTzMGtReJFRZ_2bZ_qDDTbfmLTF9mPkaKFz8LZaAO_wZnj_Vj nZwB46k8DR9tJxLJq5I1tpLVotO.3BYYDZupqla4Q8rV2pqB2uaLx_PNuftZ8Xn..pnowE5TlAFE ss0C9kB_ViC4YFz2b.L3oym1dDtn8WF7dTRuyx1lkm_W26jkEJbmFDLm9xSH4EjyvEjGNsGcjc2E UCtd7MNSgyCsI06NFxHs9S62n.h5YJf87CEuTw3cZcURUO69DckwTxzHeN1bQR2XI6DfnZpsnkmt ah0ujblnVbnmqFIjSc6EsapmSZONPCVM8KUm8EIpkwAfrUgJP_gsO8WVlxLo5xeam2ZV8FeKVJw9 hsnNnj4NrtA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Thu, 6 Sep 2018 17:32:57 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp418.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f3e61f723f48550491ae7acc9d4c41b7; Thu, 06 Sep 2018 17:32:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap) From: Mark Millard In-Reply-To: <20180906155858.GA5980@www.zefox.net> Date: Thu, 6 Sep 2018 10:32:50 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <075BD4BB-CAFB-4C9B-809A-10901522D1ED@yahoo.com> References: <20180814014226.GA50013@www.zefox.net> <20180815013612.GB51051@www.zefox.net> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <20180906003829.GC818@www.zefox.net> <20180906051520.GB3482@www.zefox.net> <059D2FED-6E7C-4FEF-8807-8D4A0D0B3E26@yahoo.com> <20180906155858.GA5980@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 17:33:03 -0000 On 2018-Sep-6, at 8:58 AM, bob prohaska wrote: > On Thu, Sep 06, 2018 at 12:08:09AM -0700, Mark Millard wrote: >> On 2018-Sep-5, at 10:15 PM, bob prohaska = wrote: >>=20 >>>> . . . >>> There were two buildworld tests run with 6 GB of swap, the first = without >>> TRIM being turned on and the second with TRIM turned on. The second = run >>> too an hour longer, with TRIM being on the only difference.=20 >>=20 >> buildworld did not take an hour longer for one vs. the other >> based on the timestamps in the log files: >>=20 >> trim off: >>=20 >>>>> World build started on Sun Sep 2 20:28:12 PDT 2018 >> . . . >>>>> World build completed on Mon Sep 3 21:35:47 PDT 2018 >>=20 >> So somewhat over 25 hours 7 minutes. >>=20 >> trim on: >>=20 >>>>> World build started on Tue Sep 4 00:02:36 PDT 2018 >> . . . >>>>> World build completed on Wed Sep 5 01:12:47 PDT 2018 >>=20 >> So somewhat over 25 hours 10 minutes. >>=20 >> I get an under 5 minute difference from those timestamps. >>=20 >>=20 >=20 > You are correct, the mistake is mine. Thanks for catching it! >=20 >>>> . . . >>> Near as I can tell there are no non-zero values for d/s, which if = it's tied >>> to TRIM is reasonable for all but microSD, which did have TRIM = enabled. Since >>> microSD wasn't particularly busy, apart from swap, that too is = unsurprising. >>=20 >> = http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/3gbsd_3gbusb/trim_on/wri= tedelay.sort >> shows ms/d and its matching kBps with the below non-zero figures: >>=20 >> . . . >> 0 0 0 0 0.0 0 6 16.2 0 10 = 0.1 0.3 mmcsd0 >> 0 0 0 0 0.0 0 6 16.3 0 10 = 0.2 0.3 mmcsd0s2 >> . . . >> 0 0 0 0 0.0 0 3 99.2 0 4 = 40.7 1.3 mmcsd0s2a >> 0 0 0 0 0.0 0 3 99.3 0 4 = 40.8 1.3 ufs/rootfs >> . . . >> 0 0 0 0 0.0 0 10 147.6 0 6 = 12.0 4.5 mmcsd0s2a >> . . . >> 0 2 1 8 1.8 0 7 211.0 0 10 = 114.5 5.8 mmcsd0 >> 0 2 1 8 1.8 0 7 211.1 0 10 = 114.5 5.8 mmcsd0s2 >> 0 1 0 0 0.0 0 7 211.2 0 10 = 114.6 5.6 ufs/rootfs >> . . . >>=20 >> Those are all I found. I may have missed some. >>=20 >=20 > Again, I was mistaken, misreading your original question.=20 I looked at examples of using 1 device for swap and only 2 GiByte of swap ( still -r338342 ): For 2gbsd (2 GiBytes on the sdcard, two 1 GiByte partitions used): World build started on Thu Aug 30 09:44:09 PDT 2018 . . . World build completed on Fri Aug 31 07:56:20 PDT 2018 So: somewhat over 22 hour and 12 minutes. vs. For 2gbusb (2 GiBytes on the usb device, two 1 GiByte partitions used): World build started on Fri Aug 31 10:27:17 PDT 2018 . . . World build completed on Sat Sep 1 12:49:19 PDT 2018 So: somewhat over 26 hours 22 minutes. So a difference of over 4 hours. It appears to me that for the devices that you are currently using, you are better off for elapsed time having the swap only on the sdcard. It may be evidence that the split of heavivly in use UFS and the swap partition across the channels/devices is useful. Or it could just be that the sdcard is faster. I can not tell from the cases available. If you had a sufficiently large sdcard of similar performance, and ran a test that avoided the usb device completely, that would give a clue (still -r338342 or otherwise matching contexts for the comparison with a split context). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Sep 7 12:21:47 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA88EFF9EEE for ; Fri, 7 Sep 2018 12:21:47 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6A44A87543 for ; Fri, 7 Sep 2018 12:21:47 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2F1D6FF9EEC; Fri, 7 Sep 2018 12:21:47 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1DD0BFF9EEA for ; Fri, 7 Sep 2018 12:21: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 882A58753E for ; Fri, 7 Sep 2018 12:21:46 +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 71f8f12b; Fri, 7 Sep 2018 14:15:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=PxJ1cvuvuHCjnIVaknYWBUfGgUA=; b=e45hx7M0PdpHE3MFl+IQNRra9/h1 xC4gPr9ZoWEyrsSoliR5qqeuzkGlxMRLiulCJLspz5zQmbNk4I4SITtXw9Lj5OqL gmtn+XtbVmI6ivhfWHVsLBK40qpvh4l2aLVjUuctw8ri1gz96gkPmqv/LgnaHA8k qMpLLgcDLSzdJ9w= 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=QFEG6e4KKy6I9vHiL5D0P6Bt7n4bm5cNL3v9Zw+tv6N/ZDaaQdEyKaJs gH935FAuE3w3SdkqefbEmrnzhweaQMYf+DGeGmqYgoHPXTdHWarcx+CgkYvVv4wN R6Oa1o4MseBIRwOkvtK7kl1O+vKrWrDEn9nCaarO9Bdugf9AD0Q= Received: from knuckles.blih.net (213.208.238.22 [213.208.238.22]) by mail.blih.net (OpenSMTPD) with ESMTPSA id dc9c62c6 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 7 Sep 2018 14:15:04 +0200 (CEST) Date: Fri, 7 Sep 2018 14:15:00 +0200 From: Emmanuel Vadot To: Daniel Braniss Cc: "freebsd-arm@freebsd.org" Subject: Re: nanopi/allwinner h3/h5/a64 and if_awg blues Message-Id: <20180907141500.8a4573ccd055843b2879d437@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; 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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 12:21:48 -0000 On Thu, 6 Sep 2018 10:08:02 +0300 Daniel Braniss wrote: > Hi, > as far as I can tell, all these platforms share the same driver, but not the same dts > in any case this is the current status: > on h3: only detected/works if cable is connected > on h5: is detected even without cable and works after cable is inserted. > Note: to get it working had to add sun50i-h5-neo2.dts to modules/dtb/allwinner/Makefile > > on a64: nothing, nada. Depend on the board. > so, any idea as to how to get it working on an sun50i-a64 (nanopi-a64)? The DTS for the NanoPi is missing the emac node. > BTW, I did get the wireless to work! What wireless ? > > cheers, > danny > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Fri Sep 7 12:48:45 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3143FFFA5F4 for ; Fri, 7 Sep 2018 12:48:45 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A635188A95 for ; Fri, 7 Sep 2018 12:48:44 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6A33CFFA5F3; Fri, 7 Sep 2018 12:48:44 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E4AFFFA5F1 for ; Fri, 7 Sep 2018 12:48:44 +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 A572188A87 for ; Fri, 7 Sep 2018 12:48:43 +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 dcc862a7; Fri, 7 Sep 2018 14:48:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=g4fNg/vyJ+5KGCqmjnot7EYctqI=; b=UepudCiPYEizo6g1iBB1ktH1DXh2 GlcitsebBPI0DSGe7eRZPuErTcSr7WeE1fdORZrFsuT9VuUabNzbAh5/UZJLHYgM NZ8M+DzDKFziMDj05NGES3YMVjNJ8EJxRsWmYDSh7u/HyPrSitfNYoO2dvW1pZ6l Oo7jTVLZhJfkp/I= 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=B7kXOoTQZEM2HcUQ171n6px5GKk4ukZfYVxi6v+rs0YxLpUcSzR/EBVi tau3aWA0EyXOQFyokXOul6R0GC9/R8lRRfH0R4Rq5NuRc8AA8ZIloBmhUQEFSrrk iRd3+1gJxtDoXivlEdfurMf28Z1YYjMBpmANnAwAu4JY8nHZ1X0= Received: from knuckles.blih.net (213.208.238.22 [213.208.238.22]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 6eacc8b9 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 7 Sep 2018 14:48:42 +0200 (CEST) Date: Fri, 7 Sep 2018 14:48:41 +0200 From: Emmanuel Vadot To: John-Mark Gurney Cc: arm@FreeBSD.org Subject: Re: Allwinner awg TX hanging issue Message-Id: <20180907144841.5f97ef0aed8f84e3cdba7932@bidouilliste.com> In-Reply-To: <20180906163547.GC75530@funkthat.com> References: <20180906163547.GC75530@funkthat.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; 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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 12:48:45 -0000 On Thu, 6 Sep 2018 09:35:47 -0700 John-Mark Gurney wrote: > Since I upgraded to a recent -current to fix the timer issue on my > A64-LTS board, I've been having an issue where the ethernet interface > will freeze. This is with: > FreeBSD gate2.funkthat.com 12.0-ALPHA4 FreeBSD 12.0-ALPHA4 #4 r338426M: Wed Sep 5 09:55:12 PDT 2018 root@gate2.funkthat.com:/usr/src/sys/arm64/compile/GENERIC arm64 > > The modified code is simply to add some dtrace probe points to debug > this issue. I also dropped the check for _OACTIVE from _start_locked. > > It prints flag at the begining of _start_locked and if _OACTIVE gets > set and at the end of _txeof if progress was made. It also prints the > progress at the end of txeof if any... It prints the val of _intr.. > > I noticed that when it was hung, the OACTIVE flag was set, but this > just means that we ran out of transmit descriptors, and was a symptom > of the problem. > > I don't have a good test to trigger this problem. This happens somewhat > regularly, every 4-12 hours on my router, but my test board, which is > lightly loaded and does not run pf doesn't have this issue. > > With the added dtrace probe points, I finally hit this: > 3 10115 none:intr intr 40000024 > 3 10115 none:intr intr 40000100 > 3 10115 none:intr intr 40000100 > 3 10115 none:intr intr 40000100 > 3 10115 none:intr intr 40000100 > 3 10114 none:flags flag 40 > 3 10115 none:intr intr 40000024 > 3 10115 none:intr intr 40000100 > 3 10114 none:flags flag 40 > 3 10115 none:intr intr 40000024 > 3 10115 none:intr intr 40000100 > 3 10114 none:flags flag 40 > 3 10115 none:intr intr 40000024 > 3 10115 none:intr intr 40000100 > 3 10114 none:flags flag 40 > 3 10115 none:intr intr 40000100 > 3 10115 none:intr intr 40000024 > 3 10115 none:intr intr 4000010a > 3 10114 none:flags flag 40 > 3 10115 none:intr intr 40000100 > 3 10114 none:flags flag 40 > 3 10115 none:intr intr 40000100 > 3 10114 none:flags flag 40 > [...] > 3 10115 none:intr intr 40000100 > 3 10114 none:flags flag 40 > 3 10114 none:flags flag 440 > 3 10115 none:intr intr 40000100 > 3 10115 none:intr intr 40000100 > 3 10115 none:intr intr 40000100 > > The intr 24 line is a normal interrupt, and will run txeof to free up > descriptors. The intr 100 line is saying the RGMII link status > changed, we don't enable it, so I'm not sure why we are getting these > interrupts (it seems like the enable bit is ignored). It looks like it's RX_INT, not RGMII_LINK_STATUS > These are > normal, and see these lines for a long while. The flag 440 line is > when we set OACTIVE, and then we see no more flag 40 lines, which > means that _start_locked doesn't get called and that _txeof doesn't > make forward progress. > > The problem point is the intr 10a line. Once we hit that line, we > never get another intr 24 line. The a is the important part of the > inter status, as it is: > > 0x8 > TX_TIMEOUT_INT > When this bit is asserted, the transmitter had been excessively active. Linux seems to stop the queue, dma, free the skbuf and restart the dma when this happens. We might need to do the same. > and: > > 0x2 > TX_DMA_STOPPED_INT > When this bit is asserted, the TX DMA FSM is stopped. > > We do not have code in the awg driver to recover from this problem. Linux only increment a stat counter when this irq is fired. > Does anyone have any ideas? > > Thanks. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Fri Sep 7 13:58:56 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CCEAFFBAAB for ; Fri, 7 Sep 2018 13:58:56 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 996D48AB79 for ; Fri, 7 Sep 2018 13:58:55 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5B35EFFBAAA; Fri, 7 Sep 2018 13:58:55 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 375E6FFBAA9 for ; Fri, 7 Sep 2018 13:58:55 +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 A80DE8AB78 for ; Fri, 7 Sep 2018 13:58:54 +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 63101a94; Fri, 7 Sep 2018 15:58:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=Hh7bJ9c970Y+kY2MxovQwo4f/OQ=; b=rUiao9UjCxu1CumEQCeICMwBeXX9 9FYqqnsw8ki2aWLRCHX4y6uKQBJ5KmH/QteFhNc02oLDt3DeLVp2+OApZirfEByc xF0nL9UYlmeBrSLJLj1kLHjZaXoAhuCVdlw7c2voNQ2gn4TZLXpgcFBHjjVT/WQ3 Thix3NneFLf+rt8= 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=qVuxCbX69HFoSe63c2N0VtNSLEO7oL9tzrpvqh6yDiYJwJsndfc8MPRR guGNGZXbtYFJ3g20+gYdG1mo3PsfiPuO+dy+xzbSl52Vds3IPLfj7Q72+b8PfPhj pgFBFZr5hGBrP/Jplwg6Zd7WQeNo28Mo35E4xY43sLkd3JN8d0A= Received: from knuckles.blih.net (213.208.238.22 [213.208.238.22]) by mail.blih.net (OpenSMTPD) with ESMTPSA id a8c8f9e8 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 7 Sep 2018 15:58:52 +0200 (CEST) Date: Fri, 7 Sep 2018 15:58:52 +0200 From: Emmanuel Vadot To: Jakob Alvermark Cc: "freebsd-arm@freebsd.org" Subject: Re: allwinner/nanopi neo boot issues Message-Id: <20180907155852.cfbfae454347ada23378e0e5@bidouilliste.com> In-Reply-To: <9a911ee0-379f-d8b0-a71a-7b5302d9e5d4@alvermark.net> References: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> <0fdbd315-f37d-e3d3-9309-612f53c4d379@alvermark.net> <8459A9BA-183A-461B-9050-3631C51218F9@cs.huji.ac.il> <474af48e-ba82-62ce-34a3-70dfc4382723@alvermark.net> <20180901224629.3997b4de29e4bf5f893dac79@bidouilliste.com> <03d4cb0a-c218-a186-936d-765261da2775@alvermark.net> <20180902172444.c4911c8c65a99a7d5e9fe8fa@bidouilliste.com> <4410f41b-79f5-f397-b0b1-84bceae82bd0@alvermark.net> <855C0010-888D-4988-8056-7788CBCF5A48@cs.huji.ac.il> <20180904181603.916a3a6fbf05ecce149f6ea1@bidouilliste.com> <79e69d73-b4f0-177a-15da-786c4101697a@alvermark.net> <20180905144108.7a2e361108cdcf3c16ed8b66@bidouilliste.com> <6a6d0683-cb07-ec4d-77f8-418d84c41f08@alvermark.net> <9a911ee0-379f-d8b0-a71a-7b5302d9e5d4@alvermark.net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; 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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 13:58:56 -0000 On Wed, 5 Sep 2018 17:34:05 +0200 Jakob Alvermark wrote: > On 9/5/18 5:24 PM, Jakob Alvermark wrote: > > > > On 9/5/18 2:41 PM, Emmanuel Vadot wrote: > >> On Tue, 4 Sep 2018 19:10:53 +0200 > >> Jakob Alvermark wrote: > >> > >>> On 9/4/18 6:16 PM, Emmanuel Vadot wrote: > >>>> On Mon, 3 Sep 2018 11:21:09 +0300 > >>>> Daniel Braniss wrote: > >>>> > >>>>>> On 3 Sep 2018, at 11:05, Jakob Alvermark =20 > >>>>>> wrote: > >>>>>> > >>>>>> > >>>>>> On 9/3/18 9:01 AM, Daniel Braniss wrote: > >>>>>>>> On 2 Sep 2018, at 19:33, Jakob Alvermark >>>>>>>> > wrote: > >>>>>>>> > >>>>>>>> On 9/2/18 5:24 PM, Emmanuel Vadot wrote: > >>>>>>>>> On Sun, 2 Sep 2018 17:14:10 +0200 > >>>>>>>>> Jakob Alvermark >>>>>>>>> > wrote: > >>>>>>>>> > >>>>>>>>>> On 9/1/18 10:46 PM, Emmanuel Vadot wrote: > >>>>>>>>>>> On Sat, 1 Sep 2018 15:50:25 +0200 > >>>>>>>>>>> Jakob Alvermark >>>>>>>>>>> > wrote: > >>>>>>>>>>> > >>>>>>>>>>>> On 8/29/18 2:22 PM, Daniel Braniss wrote: > >>>>>>>>>>>>>> On 29 Aug 2018, at 15:17, Jakob Alvermark=20 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>> >> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 8/24/18 10:02 AM, Daniel Braniss wrote: > >>>>>>>>>>>>>>>> On 24 Aug 2018, at 09:34, Daniel Braniss=20 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> hi, > >>>>>>>>>>>>>>>> with the latest current r338243 no longer boots via=20 > >>>>>>>>>>>>>>>> ubldr, efi does > >>>>>>>>>>>>>>>> but with overlays I have to manually enter the root=20 > >>>>>>>>>>>>>>>> partition. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> this is where it hangs via ubldr: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Autoboot in 8 seconds, hit [Enter] to boot or any other= =20 > >>>>>>>>>>>>>>>> key to stop > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Loading kernel... > >>>>>>>>>>>>>>>> /boot/kernel/kernel text=3D0x8a0950 data=3D0xae160+0x184= 520 > >>>>>>>>>>>>>>>> syms=3D[0x4+0xa6d70+0x4+0x109f17] > >>>>>>>>>>>>>>>> Loading configured modules... > >>>>>>>>>>>>>>>> /boot/entropy size=3D0x1000 > >>>>>>>>>>>>>>>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x601b > >>>>>>>>>>>>>>>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. > >>>>>>>>>>>>>>>> Kernel entry at 0x42400180... > >>>>>>>>>>>>>>>> Kernel args: (null) > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> older - r337232 - boots fine, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> any ideas where to look? > >>>>>>>>>>>>>>> should have done an update before writing! > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> with the latest (and greatest) all is back to normal! > >>>>>>>>>>>>>>> so now on to test orange pi one(h3), nanopi neo 2 (h5)=20 > >>>>>>>>>>>>>>> and nanopi > >>>>>>>>>>>>>>> neo a64 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> thanks, > >>>>>>>>>>>>>>> danny > >>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I am trying to get an Orange Pi R1 going, I get the same. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Loading kernel... > >>>>>>>>>>>>>> /boot/kernel/kernel text=3D0x89ee40 data=3D0xae620+0x1f5ba0 > >>>>>>>>>>>>>> syms=3D[0x4+0xa6d20+0x4+0x109e51] > >>>>>>>>>>>>>> Loading configured modules... > >>>>>>>>>>>>>> Could not load one or more modules! > >>>>>>>>>>>>>> /boot/dtb/sun8i-h2-plus-orangepi-r1.dtb size=3D0x6333 > >>>>>>>>>>>>>> Loaded DTB from file 'sun8i-h2-plus-orangepi-r1.dtb'. > >>>>>>>>>>>>>> Kernel entry at 0x42400180... > >>>>>>>>>>>>>> Kernel args: (null) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> This is at r338369. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> try booting via efi; > >>>>>>>>>>>>> make sure to copy /boot/loader.efi to=20 > >>>>>>>>>>>>> /boot/msdos/EFI/BOOT/bootaa64.efi > >>>>>>>>>>>>> remove /boot/msdos/boot.scr > >>>>>>>>>>>>> good luck, > >>>>>>>>>>>>> danny > >>>>>>>>>>>> I tried the ALPHA4 snapshot, this happens: > >>>>>>>>>>>> > >>>>>>>>>>>> Hit any key to stop autoboot:=A0 0 > >>>>>>>>>>>> switch to partitions #0, OK > >>>>>>>>>>>> mmc0 is current device > >>>>>>>>>>>> Scanning mmc 0:1... > >>>>>>>>>>>> 25395 bytes read in 4 ms (6.1 MiB/s) > >>>>>>>>>>>> Found EFI removable media binary efi/boot/bootarm.efi > >>>>>>>>>>>> Scanning disks on usb... > >>>>>>>>>>>> Disk usb0 not ready > >>>>>>>>>>>> Disk usb1 not ready > >>>>>>>>>>>> Disk usb2 not ready > >>>>>>>>>>>> Disk usb3 not ready > >>>>>>>>>>>> Scanning disks on mmc... > >>>>>>>>>>>> MMC Device 1 not found > >>>>>>>>>>>> MMC Device 2 not found > >>>>>>>>>>>> MMC Device 3 not found > >>>>>>>>>>>> Found 3 disks > >>>>>>>>>>>> 508704 bytes read in 26 ms (18.7 MiB/s) > >>>>>>>>>>>> ## Starting EFI application at 42000000 ... > >>>>>>>>>>>> Consoles: EFI console > >>>>>>>>>>>> failed to allocate staging area: 14 > >>>>>>>>>>>> failed to allocate staging area > >>>>>>>>>>>> ## Application terminated, r =3D 5 > >>>> =A0=A0 So this is weird, it mean that loader.efi couldn't allocate s= ome=20 > >>>> pages. > >>>> > >>>> =A0=A0 I've just tried ALPHA4 on my orangepi-zero (closer board that= I=20 > >>>> have), > >>>> I've just overwritten u-boot using the port we have for it and the > >>>> board boots just fine. > >>>> =A0=A0 How did you generate the image for this one ? > >>>> =A0=A0 Could you test with my method ? Thanks. > >>> Which image should I use? For ALPHA3 there is a GENERICSD image, but= =20 > >>> not > >>> for ALPHA4. > >> =A0 Build fail due to some (maybe) race condition. > >> > >>> I just tried with > >>> FreeBSD-12.0-ALPHA4-arm-armv7-CUBIEBOARD2-20180831-r338410.img > >> =A0 Any of the armv7 image will do, they are all the same except the > >> u-boot part. > >> > >>> dd the u-boot from the port (latest one, u-boot-orangepi_r1-2018.07_3) > >>> > >>> Put the SD card in and this happened: > >>> > >>> Hit any key to stop autoboot:=A0 0 > >>> switch to partitions #0, OK > >>> mmc0 is current device > >>> Scanning mmc 0:1... > >>> 25395 bytes read in 3 ms (8.1 MiB/s) > >>> Found EFI removable media binary efi/boot/bootarm.efi > >>> Scanning disks on usb... > >>> Disk usb0 not ready > >>> Disk usb1 not ready > >>> Disk usb2 not ready > >>> Disk usb3 not ready > >>> Scanning disks on mmc... > >>> MMC Device 1 not found > >>> MMC Device 2 not found > >>> MMC Device 3 not found > >>> Found 3 disks > >>> 508704 bytes read in 25 ms (19.4 MiB/s) > >>> ## Starting EFI application at 42000000 ... > >>> Consoles: EFI console > >>> failed to allocate staging area: 14 > >>> failed to allocate staging area > >>> ## Application terminated, r =3D 5 > >>> EFI LOAD FAILED: continuing... > >>> > >>> > >> =A0 Could you try to decrease EFI_STAGING_SIZE to 32 in > >> stand/efi/loader/copy.c ? > > > > Didn't make any difference: > > > > Found EFI removable media binary efi/boot/bootarm.efi > > Scanning disks on usb... > > Disk usb0 not ready > > Disk usb1 not ready > > Disk usb2 not ready > > Disk usb3 not ready > > Scanning disks on mmc... > > MMC Device 1 not found > > MMC Device 2 not found > > MMC Device 3 not found > > Found 3 disks > > 508704 bytes read in 26 ms (18.7 MiB/s) > > ## Starting EFI application at 42000000 ... > > Consoles: EFI console > > failed to allocate staging area: 14 > > failed to allocate staging area > > ## Application terminated, r =3D 5 > > EFI LOAD FAILED: continuing... >=20 >=20 > Disregard that. I copied the wrong file. >=20 > I boots with EFI_STAGING_SIZE set 32. Ok, thanks. I'm wondering if we should try with EFI_STAGING_SIZE/2 if the first allocate_pages failed ... >=20 >=20 > > > >> =A0 We currently request 64M for the staging size which seems to be too > >> big for this board. > >> =A0 U-Boot cannot find enough memory it seems, > >> https://elixir.bootlin.com/u-boot/latest/source/lib/efi_loader/efi_mem= ory.c#L300=20 > >> > >> > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Fri Sep 7 15:29:54 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 527E0FFDAF4 for ; Fri, 7 Sep 2018 15:29:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DB8FC8DA67 for ; Fri, 7 Sep 2018 15:29:53 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id A00ECFFDAF3; Fri, 7 Sep 2018 15:29:53 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8EB1FFFDAF2 for ; Fri, 7 Sep 2018 15:29:53 +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 1B46E8DA66 for ; Fri, 7 Sep 2018 15:29:52 +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 1fyIhV-0009za-Aw; Fri, 07 Sep 2018 18:29:37 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: nanopi/allwinner h3/h5/a64 and if_awg blues From: Daniel Braniss In-Reply-To: <20180907141500.8a4573ccd055843b2879d437@bidouilliste.com> Date: Fri, 7 Sep 2018 18:29:37 +0300 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <256B3CE1-92E5-4450-B5FE-B32D1FB20005@cs.huji.ac.il> References: <20180907141500.8a4573ccd055843b2879d437@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 15:29:54 -0000 > On 7 Sep 2018, at 15:15, Emmanuel Vadot wrote: >=20 > On Thu, 6 Sep 2018 10:08:02 +0300 > Daniel Braniss wrote: >=20 >> Hi, >> as far as I can tell, all these platforms share the same driver, but = not the same dts >> in any case this is the current status: >> on h3: only detected/works if cable is connected >> on h5: is detected even without cable and works after cable is = inserted. >> Note: to get it working had to add sun50i-h5-neo2.dts to = modules/dtb/allwinner/Makefile >>=20 >> on a64: nothing, nada. >=20 > Depend on the board. >=20 >> so, any idea as to how to get it working on an sun50i-a64 = (nanopi-a64)?=20 >=20 > The DTS for the NanoPi is missing the emac node. any hints? I tried several different overlays(borrowing stuff from pine) = but so far the best i got was: awg0: mem 0x1c30000-0x1c3ffff irq 32 on = simplebus0 awg0: PHY type: rmii, conf mode: reg awg0: EMAC clock: 0x00002000 awg0: AHB frequency 150000000 Hz, MDC div: 0x2 awg0: cannot attach PHY device_attach: awg0 attach returned 6=09 >=20 >> BTW, I did get the wireless to work! >=20 > What wireless ? Ah, just realised, there is an onboard, but that is not supported. I succeeded with a dongle - can=E2=80=99t remember off hand which, but = the reason I mentioned it was that the dongle does not work on the other socs, so at least on the nano-a64 i = have some network connectivity. >=20 >>=20 >> cheers, >> danny >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >=20 >=20 > --=20 > Emmanuel Vadot From owner-freebsd-arm@freebsd.org Fri Sep 7 15:47:02 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 796C5FFE13A for ; Fri, 7 Sep 2018 15:47:02 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1717F8E424 for ; Fri, 7 Sep 2018 15:47:02 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id CFD18FFE139; Fri, 7 Sep 2018 15:47:01 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94200FFE138 for ; Fri, 7 Sep 2018 15:47:01 +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 158318E423 for ; Fri, 7 Sep 2018 15:47:00 +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 eda25621; Fri, 7 Sep 2018 17:46:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mail; bh= g/nbN6TPbOQBbH9bYmW4K4BvEbE=; b=mDmGdfu3ICJv8a4Spmsh3AvBOgQOhXul b7XmFWIrsSvakE4PXxYLZ7/dagiJLO5QES5lgOPxNBiq/IrZu6ag+uoirwnIhaIk W1YvIhWG/hZBSAK1tOHmWnxBB//q3XiZahbZQDOv9Sa1K8GGXPKLzCo2KV4eDR/d bqiiFb1cKAw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= mail; b=oG0am9QRZoAodEU0iU+RwkGnPnwsV5i0qGUgbRIK9CNxShkhjKR8lf3a GatWdiDuixCWV0/sfYbK/TU9vvZi7MOTopCLW1UaiHlK1f570Qh2P6S0ejsKQcp+ 0Gg8RKRXRWftXqOOtXv6f3EhURPH3Hk2rD0CApQnE1GpRBPWWVM= Received: from [10.43.102.157] (37.173.149.69 [37.173.149.69]) by mail.blih.net (OpenSMTPD) with ESMTPSA id b90bb9cf TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 7 Sep 2018 17:46:59 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: nanopi/allwinner h3/h5/a64 and if_awg blues From: Emmanuel Vadot X-Mailer: iPhone Mail (15G77) In-Reply-To: <256B3CE1-92E5-4450-B5FE-B32D1FB20005@cs.huji.ac.il> Date: Fri, 7 Sep 2018 17:46:55 +0200 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180907141500.8a4573ccd055843b2879d437@bidouilliste.com> <256B3CE1-92E5-4450-B5FE-B32D1FB20005@cs.huji.ac.il> To: Daniel Braniss X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 15:47:02 -0000 --=20 Emmanuel Vadot > Le 7 sept. 2018 =C3=A0 17:29, Daniel Braniss a =C3=A9= crit : >=20 >=20 >=20 >> On 7 Sep 2018, at 15:15, Emmanuel Vadot wrote: >>=20 >> On Thu, 6 Sep 2018 10:08:02 +0300 >> Daniel Braniss wrote: >>=20 >>> Hi, >>> as far as I can tell, all these platforms share the same driver, but not= the same dts >>> in any case this is the current status: >>> on h3: only detected/works if cable is connected >>> on h5: is detected even without cable and works after cable is insert= ed. >>> Note: to get it working had to add sun50i-h5-neo2.dts to modules/= dtb/allwinner/Makefile >>>=20 >>> on a64: nothing, nada. >>=20 >> Depend on the board. >>=20 >>> so, any idea as to how to get it working on an sun50i-a64 (nanopi-a64)?=20= >>=20 >> The DTS for the NanoPi is missing the emac node. > any hints? I tried several different overlays(borrowing stuff from pine) b= ut so far the best i got was: >=20 you should try a dts from linux 4.19 or later maybe it have the node. I=E2=80=99m away from this board right now so can=E2=80=99t test myself. > awg0: mem 0x1c30000-0x1c3ffff irq 32 on simpl= ebus0 > awg0: PHY type: rmii, conf mode: reg > awg0: EMAC clock: 0x00002000 > awg0: AHB frequency 150000000 Hz, MDC div: 0x2 > awg0: cannot attach PHY > device_attach: awg0 attach returned 6 =20 >=20 >>=20 >>> BTW, I did get the wireless to work! >>=20 >> What wireless ? > Ah, just realised, there is an onboard, but that is not supported. > I succeeded with a dongle - can=E2=80=99t remember off hand which, but the= reason I mentioned it was that the > dongle does not work on the other socs, so at least on the nano-a64 i have= some network connectivity. >=20 >>=20 >>>=20 >>> cheers, >>> danny >>>=20 >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >>=20 >>=20 >> --=20 >> Emmanuel Vadot From owner-freebsd-arm@freebsd.org Fri Sep 7 20:37:11 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06C57106B9D3 for ; Fri, 7 Sep 2018 20:37:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-12.consmr.mail.bf2.yahoo.com (sonic304-12.consmr.mail.bf2.yahoo.com [74.6.128.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4E9B76BD7 for ; Fri, 7 Sep 2018 20:37:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: L_rGxlUVM1k0kno0dWSZEmH1nz7BVGoCicF340QKDAa8E__5S4gu3KEGf_Xj.p3 He4rwc7NnuMLFRfO8Crz32BL4k4f1sEY9tFitKj4a5aQNBGy9XcQLLbzN9B9SERNMR6OrMBOwuFs urfFkxbapYog24rgCL2y0Ac9iKjc601SXY4IwjWUb9.PT7z7emsLgfKJAffs4lGwdFHbd_t_1A68 pvn4mRyCmMZQQvrmfvYQ5XiU87oyMzrK880ppCjhsqfinapEg8Wap8aRfUxxDSi69b6x_mYxuFmV dXekeC9R4ftKen1rQCjeFDk_0njJ6ZfeRg1Nm.usPmYVcxG7l48nGOnpEh5.GTgsndtCrqA_fF92 qKEdepPFsgyvt83y4pvCBUGKCWave.I1M0tr2NHXMHz47sMnipCfiy1rNR.yicw3CGR7Ly6XcQkM R7.tTJfBt.3ESNRHEwSPbPhNaJSB_pC.H9rpHokik8G44CxwR_FyXpiKHN0YXTg.KD4f9PZwebDq aU7PjnXhHmIw6GjLu2FErQyYOS2VGka8CpJqFb3QVSoMeg1zHuFmrbKgSLVUREmGIlidROi_Roc6 Gb3eDmVa9YyTysbmIuMH7cnhOivKfG2JyGWKRC7WvLoPONbJuiLMn0Vs0M2aN0_KZ8mSvjl8QHGP ZFnk1UwOWPbBs5QqJtUHdJnbf9PA0xavMtcS13PWqnuA8lIqN7bH4XmOagSbYfDdtogZrEbW4KSx M1DgsOuT3tZ5p90DECgcoqU0Yt1pT0JJXAa2jxzcdAftZlgEy.IW9ZqOSas8DdTPKtCdvc3AT7pW yAZO2c._sAi9iYf8tAglHqFAnXqVjTT2vUtRqvHPh3_kVdveezwufLLZdB1Zd8PW_Zh1v9Nl.6nC 1WZmT.J4yPN1747j9vPNNGFxZ.5opzDN_q_W_MC8F5Wiv0x.xLkrmmLpAM6P59Ojsnxlx.qpPCJl .R9mQaLedUtCu9Bghm1HEPgLdiVkd5THP.absdnc1dtTidXGhSS1IFiUkzA_Vasb9qIhcyQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Fri, 7 Sep 2018 20:37:09 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp430.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 722ee6b45f558b207d3574cb36f95fe2 for ; Fri, 07 Sep 2018 20:37:07 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Just an FYI: debug kernel output for an e.MMC on a sdcard adapter (Pine64+ 2GB context, head -r338518 based) Message-Id: <73FE40F2-9D13-4A43-9B03-E8452DC146A9@yahoo.com> Date: Fri, 7 Sep 2018 13:37:05 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 20:37:11 -0000 I built and installed a debug kernel with "options VERBOSE_SYSINIT" as well and I added "hw.mmc.debug=3D1" to /boot/loader.conf and used boot -v just to see what such a combination would report for the Pine64+ 2GB attempting to boot from the e.MMC with that kernel on it. The boot_run_interrupt_driven_config_hooks area ended up looking like (serial numbers replaced): QUOTE subsystem a800000 boot_run_interrupt_driven_config_hooks(0)... aw_mmc0: Powering up = sd/mmc axp8xx_pmu0: Enable vcc-3v3 (dcdc1) mmc0: Probing bus ugen1.1: at usbus1 uhub0: on = usbus1 ugen2.1: at usbus2 uhub1: on = usbus2 ugen3.1: at usbus3 uhub2: on = usbus3 ugen0.1: at usbus0 uhub3: on = usbus0 Expensive timeout(9) function: 0xffff0000004149f8(0) 0.002082708 s aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 mmc0: CMD8 RESULT: 1 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 mmc0: CMD8 RESULT: 1 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 mmc0: CMD8 RESULT: 1 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 mmc0: CMD8 RESULT: 1 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 mmc0: CMD55 RESULT: 1 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 mmc0: CMD55 RESULT: 1 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 mmc0: CMD55 RESULT: 1 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 mmc0: CMD55 RESULT: 1 mmc0: SD probe: failed mmc0: MMC probe: OK (OCR: 0x40ff8080) mmc0: Current OCR: 0x00ff8080 mmc0: Probing cards mmc0: New card detected (CID 150100444a4e42345207???????636f) mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) aw_mmc0: error rint: 0x00008018 AW_MMC_INT_DATA_END_BIT_ERR mmc0: CMD19 RESULT: 4 mmc0: Card at relative address 0x0002 added: mmc0: card: MMCHC DJNB4R 0.7 SN MFG 06/2016 by 21 0x0000 mmc0: quirks: 0 mmc0: bus: 4bit, 200MHz (HS200 timing) mmc0: memory: 244277248 blocks, erase sector 1024 blocks aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 mmc0: CMD2 RESULT: 1 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 mmc0: CMD2 RESULT: 1 aw_mmc0: error rint: 0x00000100 AW_MMC_INT_RESP_TIMEOUT=20 mmc0: CMD2 RESULT: 1 uhub0: 1 port with 1 removable, self powered aw_mmc0: error rint: 0x00000104 AW_MMC_INT_RESP_TIMEOUT=20 mmc0: CMD2 RESULT: 1 mmc0: setting transfer rate to 52.000MHz (dual data rate timing) uhub2: 1 port with 1 removable, self powered mmc0: Failed to set VCCQ for card at relative address 2 uhub1: 1 port with 1 removable, self powered uhub3: 1 port with 1 removable, self powered aw_mmc0: controller timeout aw_mmc0: timeout updating clock Expensive timeout(9) function: 0xffff00000068400c(0xfffffd00001bd400) = 11.120601791 s mmc0: CMD8 RESULT: 1 aw_mmc0: controller timeout aw_mmc0: timeout updating clock mmc0: CMD8 RESULT: 1 aw_mmc0: controller timeout aw_mmc0: timeout updating clock mmc0: CMD8 RESULT: 1 aw_mmc0: controller timeout aw_mmc0: Spurious interrupt - no active request, rint: 0x00000000 mmc0: CMD8 RESULT: 1 mmcsd0: Error reading EXT_CSD Timeout device_attach: mmcsd0 attach returned 6 done. vt_upgrade(&vt_consdev)... done. subsystem affffff END QUOTE You may want to ignore my guesses below . . . If I gather right, the part before: mmc0: MMC probe: OK (OCR: 0x40ff8080) is as expected. I'm not sure about: aw_mmc0: error rint: 0x00008018 AW_MMC_INT_DATA_END_BIT_ERR mmc0: CMD19 RESULT: 4 The part between: mmc0: bus: 4bit, 200MHz (HS200 timing) and: mmc0: setting transfer rate to 52.000MHz (dual data rate timing) may well be as expected. I'm guessing that the following is the odd part that contributes to device_attach returning 6: aw_mmc0: controller timeout aw_mmc0: timeout updating clock Expensive timeout(9) function: 0xffff00000068400c(0xfffffd00001bd400) = 11.120601791 s mmc0: CMD8 RESULT: 1 aw_mmc0: controller timeout aw_mmc0: timeout updating clock mmc0: CMD8 RESULT: 1 aw_mmc0: controller timeout aw_mmc0: timeout updating clock mmc0: CMD8 RESULT: 1 aw_mmc0: controller timeout aw_mmc0: Spurious interrupt - no active request, rint: 0x00000000 mmc0: CMD8 RESULT: 1 mmcsd0: Error reading EXT_CSD Timeout device_attach: mmcsd0 attach returned 6 One thing looking different than linux booting from such a e.MMC on a sdcard adapter may be the 52.000MHz. Linux showed: # cat /sys/kernel/debug/mmc0/ios clock: 52000000 Hz actual clock: 50000000 Hz . . . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Sep 8 06:17:19 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 737DBFE9282 for ; Sat, 8 Sep 2018 06:17:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 002F3881A3 for ; Sat, 8 Sep 2018 06:17:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: sp57OZkVM1mVMiDbmrRKwT3iSQrEtCfk76gzZifFoclLbzkop9ea3kAE21kC_l_ Ez7SL1RKSHKNCd7NOZSNDCg5PLcPaE0pI4LZdspubLnm_ko8EkVpTv7uBhaBJ_lrwWQAw1soCP7F Q6MoBZZOJC2Prvybj1G.tLE.gour_fnNlkNXOlzqI_ikx2k_ZdMBj8Kok5WKtguldb6eUXyEVDBq bQMEFnWbh3S8Ot3jLt2XyQm5YsW5O8e5Jm70kRXuq2eb7mS125lhtU_0LGVVmFze6zi1yG4iZUFF 0FFYDsom8GC1SBZ8LAk97CG8.1yzFV1ONWqQMGLa9qp.e__IzYZo.3Ut.XVgcxL15d5MpfdWwnSt nBPquVOBa1dnbaCNWsf4MtmpL9RQE9kS5i8br.X9qiphWbH.jmejttAa1BtZ.iA5dEPuKllbjD9S GUtRyyRp9e0L05KbnKWnRuu9igAIOjgE6iG.DBG9M7nsjV_0O4J7aCph5t3ek1WKcEh0lOEmRxIf fpqYofS4MTg3NszKF39agc0VnnhmQtz25naQBCKtEvC3OoEGLQEqtY_zw9hJH1l8IfpwlA3uabdt 64UKYamXMcHY_JSAXfEf6ikj2zw_AsXMRuuZi91Wvf2SCrIe1KhDntDGuv4XlWLCd5Bo178pXonE PxubLkFtaZTP51ea5lSCKv05P1emoyBabE_vpyQVtft.sB8kxacJOMAfvbHL85KJdGVKbEk_KwzP FKPatoK.WXo69h2mxv.wOaSaxpBJ9HljwX3CL6FEmyUgObrKO.sJTZhtg5G36uzRmt1Aw7ENHu0o qAsag1ZJcZQwawf7AuJDB.CilC9KotT18CCrPvyc.vHer5Ob.l58C2j_Y8SUG8UrMqwQ52GdX.fB YcX7Wrz3_2reinsBC8ZuhFWJnzFHIdV5eWGHGZ42lIo.EwbbgJ3p_docm5pxsQzeGtAPo9K1h4B3 9DzDv3ld1PN.a9qGltW6vI4RIuZK4fEqaKgf6Vx6_TmEjkf0OKGAwzIA8UFj9eIxfKJeNFNhisYU K1fh2UyIBdQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 8 Sep 2018 06:17:11 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp413.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID fadb5510a7785e9b25142eaa97deb3f3; Sat, 08 Sep 2018 06:17:10 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: An experimental hack that makes head -r338518 boot from e.MMC via an microsd card adapter, in DDR52 mode at that Message-Id: <6D375D5B-34E2-4124-9A32-92C320AD6A54@yahoo.com> Date: Fri, 7 Sep 2018 23:17:09 -0700 Cc: Emmanuel Vadot , Marius Strobl To: freebsd-arm X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 06:17:19 -0000 The following hack demonstrates what is blocking the use of e.MMC on an adapter on the Pine64+ 2GB that I can test with (and likely more). In essence the hack makes the code ignore "Failed to set VCCQ" for DDR52 and so use the default VCCQ and keep going. # svnlite diff /usr/src/sys/dev/mmc/mmc.c = = =20 Index: /usr/src/sys/dev/mmc/mmc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/dev/mmc/mmc.c (revision 338518) +++ /usr/src/sys/dev/mmc/mmc.c (working copy) @@ -2226,7 +2226,7 @@ if (mmc_set_vccq(sc, ivar, timing) !=3D = MMC_ERR_NONE) { device_printf(dev, "Failed to set VCCQ = for " "card at relative address %d\n", = rca); - continue; + //continue; } } But that does not show what ended up executing instead. So, giving more context: if (timing =3D=3D bus_timing_mmc_ddr52) { /* * Set EXT_CSD_BUS_WIDTH_n_DDR in = EXT_CSD_BUS_WIDTH * (must be done after switching to = EXT_CSD_HS_TIMING). */ if (mmc_set_card_bus_width(sc, ivar, timing) !=3D MMC_ERR_NONE) { device_printf(dev, "Card at relative = address " "%d failed to set bus width\n", = rca); continue; } mmcbr_set_bus_width(dev, ivar->bus_width); mmcbr_update_ios(dev); if (mmc_set_vccq(sc, ivar, timing) !=3D = MMC_ERR_NONE) { device_printf(dev, "Failed to set VCCQ = for " "card at relative address %d\n", = rca); //continue; } } =20 /* Set clock (must be done before initial tuning). */ mmcbr_set_clock(dev, max_dtr); mmcbr_update_ios(dev); . . . power_class: if (mmc_set_power_class(sc, ivar) !=3D MMC_ERR_NONE) { device_printf(dev, "Card at relative address %d = " "failed to set power class\n", rca); } This is inside the loop: for (i =3D 0; i < sc->child_count; i++) { in: static int mmc_calculate_clock(struct mmc_softc *sc) in: /usr/src/sys/dev/mmc/mmc.c The result is: mmc0: setting transfer rate to 52.000MHz (dual data rate timing) mmc0: Failed to set VCCQ for card at relative address 2 mmcsd0: 125GB at = mmc0 52.0MHz/4bit/32768-block mmcsd0boot0: 4MB partion 1 at mmcsd0 mmcsd0boot1: 4MB partion 2 at mmcsd0 mmcsd0rpmb: 4MB partion 3 at mmcsd0 . . . It boots to an operating multi-user environment just fine. (I've not yet done things like buildworld or poudriere bulk.) As evidence of DDR52 instead of High Speed: # dd if=3D/dev/mmcsd0 of=3D/dev/null bs=3D1m ^C 811+0 records in 811+0 records out 850395136 bytes transferred in 20.315078 secs (41860294 bytes/sec) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Sep 8 07:52:49 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E07BFEB945 for ; Sat, 8 Sep 2018 07:52:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-22.consmr.mail.bf2.yahoo.com (sonic312-22.consmr.mail.bf2.yahoo.com [74.6.128.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 19C7E8AB33 for ; Sat, 8 Sep 2018 07:52:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: LtTwW0MVM1mPLG_63ID8DWVHiMLdSy.rFSF6PPM03AsqUpq5RU1ewkEgV.pxQ5e TWxlhydKXTifqcPweb733JRKpGGyjQDNA87y0UZ9UPGpOtwiNiOGWnBVefAs5QOcL2HvV_cUtbW5 fFEPxHTvmVp4P.3wsiGWq9In2aSWLIutlOXcL4rZfkPf9IBJkdxFeBoDBgM6uF6wfMrJyz5E1bjX nAkWP9c1YkZs0frXBuGoVrWlrsgDdbs6eADYFp9Uk3HTXze.SnbXKqsKLljshQexjenaPdFV9hVi wR4LunHA8Oh8x4qmoh7w2GCLOEt0uubWH53ZbZlLlMKUzzJ7Py2pNrYs4MNotaZMpeMLtaTVn0Fd XSwlTCbz0LqCeNNQZeE6BQIC1whfp5qsJbY0drezPZuIPsvsyxj9zZEddkztLG5KlMZcrL1yleDD d9Oox5DQpNOalKl3QfDI2WNj0589snU3wIQjF2.6SZLiZJQzSpzLxHMP7RhHrBXcUp_5K1T67tAJ fVyKrDfRjF9YfIFCzF7pqABXQd667pF6qRVYeyuZ5u.uVVAFzcACqyWAmjbXyhaKgGR4rzflCcAt zeXKJM1PhNtKTA45x9cyW30FwIDuMZ819.dpaLm3yOzlYUymZWAUBVluTReUG14gYlMua_TxmRsX _2Cn2M.d.9hRjQZAWz9tG.Yl_IdA5tDZJ3rm9Xmw767FoA90IywvzgxfUL5uR7bsSRQ_lTlbC6QQ ONZWdxD1qOOHxV.zo00mplb1lR_vNhY.LaMtNDxP1QtqgmPySJrCC.gCPPqmNfXPD37Fy_8.OoN9 MS2K9YMqw.CfIFto95DJrY9j_iiY6qVsEmnmHwsTVeuYJgsmgAqL.x1tF8QgnCgoqQlbp9IDU0Lx w2hlRJ79e4riobtED2oGxtMElFqB2dVnddQTnrgY3ESJYSrOeKJc_ORZhNUBMo3NJmm7NkF.V2Y_ 5Cw_2QHZXFUHvm_e0Q1rkpQdHdAUt5eFjuUA0sg4rGd7JUmb.r1Qx3i8Jt.4vOHnlhax7uA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Sat, 8 Sep 2018 07:52:41 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp408.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 22fcde8d053a94e65e4a709c08499438 for ; Sat, 08 Sep 2018 07:52:40 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: A possible e.MMC CMD protocol violation? Message-Id: <10C361F4-9DA4-4FD8-9D33-13112AE41DA4@yahoo.com> Date: Sat, 8 Sep 2018 00:52:38 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 07:52:49 -0000 In my investigation that lead to a hack that allows use of e.MMC on a microsd card adapter to boot a Pine64+ 2GB, I ran into a separate, earlier in time issue that seemed to contradict what I was reading about the e.MMC protocol's Device states and what operations are allowed/expected in each state vs. not being allowed/expected. In: mmc0: Card at relative address 0x0002 added: mmc0: card: MMCHC DJNB4R 0.7 SN 9F43B2E7 MFG 06/2016 by 21 0x0000 mmc0: quirks: 0 mmc0: bus: 4bit, 200MHz (HS200 timing) mmc0: memory: 244277248 blocks, erase sector 1024 blocks mmc0: REQUEST: CMD7 arg 0 flags 0 uhub2: 1 port with 1 removable, self powered mmc0: REQUEST: CMD2 arg 0 flags 0x67 AW_MMC_INT_RESP_TIMEOUT mmc0: CMD2 RESULT: 1 mmc0: REQUEST: CMD2 arg 0 flags 0x67 AW_MMC_INT_RESP_TIMEOUT mmc0: CMD2 RESULT: 1 mmc0: REQUEST: CMD2 arg 0 flags 0x67 AW_MMC_INT_RESP_TIMEOUT mmc0: CMD2 RESULT: 1 mmc0: REQUEST: CMD2 arg 0 flags 0x67 AW_MMC_INT_RESP_TIMEOUT mmc0: CMD2 RESULT: 1 the context has already been classified as mmc instead of sd for the media. The: mmc0: REQUEST: CMD7 arg 0 flags 0 is always a "device is not addressed" CMD7 and does one of the following state transitions: tran -> stby data -> stby prg -> dis irq -> stby No other current-states allow/expect CMD7. But for: mmc0: REQUEST: CMD2 arg 0 flags 0x67 there is only: ready -> ident (device wins bus) ready -> ready (device loses bus) irq -> stby (both win and lose) No other current-states allow/expect CMD2. So stby and dis do not. (I got this from a "Device state transitions" table.) Yet the sequence above is that form of CMD7 followed by 4 failing retries of CMD2. Seems odd to me, unless I've misinterpreted something. It may be that the CMD2's are only slightly wasteful so the "always an error" statue might be a very minor violation. [This all resulted from attempting to re-enable using media that I used to use in the Pine64+ 2GB microsd card slot and in other example microsd card slot contexts. For now I've only access to the Pine64+ 2GB as something with a microsd card slot. But I'm hoping to have all the examples work when I again have access. The above does not block use but I figured I'd mention it.] === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)