From owner-freebsd-arm@freebsd.org Sun Mar 24 23:55:46 2019 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 AEC691548EB4 for ; Sun, 24 Mar 2019 23:55:46 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (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 02DCD6DE12 for ; Sun, 24 Mar 2019 23:55:45 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1553471739; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=vO7oUk3FSFih6jOaXNzSy1+zUym+wByjMnCrgwrTpq7KQqrP6FQ/b5JUYMXYEjGs+eb1SjY0ZRXC0 h4XRzYhLIq/o39aOdPElV4Ne6jKAneRcHkoTy25j1QVNKNM4msM8bvBOQamWxp7Zo6tlnkICdsz228 U3WSitWt8Rd5votPLuwBu2GpM7SpyTx5r4TFMJ3XRfDc7nl6Q15UZjbgbdlYJq43oVgIqrX9rWkoJj aZIz8Upyu2sk4Y8qrpw1Hyt0VH35fy+8ZZDGGIIuftMRFax4KWUHN4iR7fazk36KLpufEpzoVpD3+/ tgrAy9smiTVZ6OM/L+dNvHb6LTFgdyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=zH0b1PjQ6U8hrWCKK1cE6NRoeeZ4pavXQhqd4+wuvrs=; b=U2+U/eCfN3t5Ts/AIBz17ADahR0HJnynpUKczMgLNOIm8Cd5j6jX7NpIMfVeO5/FVaoQ1JXf7bJVq WXDsvGJa6b8RJsMzqX6kG9zkbjeHOKEtYgJMPyV5eeQXEubRTZXYW/QGn23qUm1rRnlXfbgNtSTtT1 xz+cR7e2x6LdNI5Higf24vA7EhSVDnNLVHtWEw5ewpqOvknmTdn8XJXBGuQ0BSG0OLh8oZ3Dk/NToc K0Z6r61DptC+/nJW9go50bbWUpojMpZfb8gxHnn/NiH82DlD4QUcLUUMbK+4bFf4Zr2j5c7tW/mMcD 17H08TQK4mZg3yTNwE+N1bcB9oAu8cg== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=zH0b1PjQ6U8hrWCKK1cE6NRoeeZ4pavXQhqd4+wuvrs=; b=CvsmoQWGsa05z6BDtdMMzdtgUu/5X9FQX5eH/HAwAdxdWX/wG2tqRqE2idWDTgNN3/IoiRjJjDVs5 UGxsFP8cFbCw/yzYSa0zijZHplLTIUstUrW1GTtTKzi+s47aSUYdOnOCbNYn/vuRnWllwynn4rkKo8 +SDT6TKjRNy1OMAA7Eby1NnfzVbAMVaG6h8LwkkCa89zSUcZyq1OQ8qkPfk2UynuEK5SfMgeq0NHsi 2j9ILvVvqbxM9x28rUlh172W9FZTt+Qow6gjny5L5P4u6knJu4s4SFrDPZ6K7DMLmpKjfqdKUP6iq2 7TwnT18u3lhhXURaXB0P73GeUInvjuA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 50bf6a49-4e90-11e9-9bb1-1f29e4676f89 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 outbound3.ore.mailhop.org (Halon) with ESMTPSA id 50bf6a49-4e90-11e9-9bb1-1f29e4676f89; Sun, 24 Mar 2019 23:55:37 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x2ONtXor081106; Sun, 24 Mar 2019 17:55:34 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] From: Ian Lepore To: ticso@cicely.de, Karl Denninger Cc: freebsd-arm@freebsd.org Date: Sun, 24 Mar 2019 17:55:33 -0600 In-Reply-To: <20190319161423.GH57400@cicely7.cicely.de> References: <8df902f6-20a3-31c4-71ac-91f5d5fdf50d@optiplex-networks.com> <0ecf23e129ca7ac6a92a01bbb34c03f1ac8c6dc8.camel@freebsd.org> <89f5b8d1ab0614ac8d88b5d5f1afc63e640c3c17.camel@freebsd.org> <4EB5C6C1-7DB9-4DEE-BB23-CD1259581271@jeditekunum.com> <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> <20190319161423.GH57400@cicely7.cicely.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 02DCD6DE12 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-3.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-1.00)[-0.996,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 23:55:46 -0000 On Tue, 2019-03-19 at 17:14 +0100, Bernd Walter wrote: > On Tue, Mar 19, 2019 at 09:55:12AM -0500, Karl Denninger wrote: > > On 3/19/2019 09:26, Jedi Tek'Unum wrote: > > > On Mar 18, 2019, at 2:57 PM, Ian Lepore wrote: > > > > On Mon, 2019-03-18 at 14:51 -0500, Jedi Tek'Unum wrote: > > > > > My impression wasn???t that support wasn???t there - but > > > > > ???out of the box??? > > > > > configuration wasn???t there. In comparison, I didn???t have > > > > > to do > > > > > anything to get I2C enabled in the binary distribution of > > > > > Linux that > > > > > comes through the manufacturer. > > > > > > > > > > Its the enabling part that isn???t obvious to most people > > > > > IMO. > > > > > > > > > > Documentation/wiki is great. But even better would be all the > > > > > enabling overlays already in place and the entries in > > > > > loader.conf > > > > > already there and commented out. It would be so much easier > > > > > to go to > > > > > a ???common place??? (loader.conf), skim through the notes, > > > > > find the > > > > > thing that one wants, and then just uncomment the referenced > > > > > line! > > > > > (Or any other similarly easy method.) > > > > > > > > > > > > > > > For FBSD to get a better foothold in this space it needs to > > > > > be better > > > > > documented. For example, the wiki for NEO2 < > > > > > http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2>; is a > > > > > step-by- > > > > > step guide for how to acquire and configure Linux for it. > > > > > > > > > > > > > > > > > > On one of my imx6 boards I have 5 SPI devices. Each device can > > > > use 3 > > > > or 4 different sets of pins for clock, data-in, and data- > > > > out. Plus, > > > > each can use literally any number of whatever gpio pins they > > > > want as > > > > chip selects. Even limiting the chipsels to a handfull, there > > > > would > > > > literally be thousands of possible combinations of devices and > > > > pin > > > > configurations, each one needing to be a separate overlay. > > > > > > > > Maybe you have experience primarily with rpi or some similarly > > > > crippled > > > > devices that only offer one or two choices? > > > > > > If memory serves correctly, there are only 2 I2C devices on the > > > H3/H5 and the NanoPi NEO/2 implementations only externalize 1. > > > There is only 1 SPI AFAIK. > > > > > > I wouldn???t call that crippled. I chose this platform exactly > > > because of its characteristics - small, fast, cheap. It fits the > > > project I???m using it for perfectly. In fact, I can see uses for > > > even smaller (see Giant Board > > >). I understand other projects may have different requirements > > > and would drive one towards different solutions - and require > > > more of the various interfaces. But they aren???t going to be > > > typical of hobbyist projects. > > > > > > Maybe I should pose the question in another way. What is the > > > philosophy for choosing GPIO as default for all the pins? These > > > boards have a very limited number of pins and my preference would > > > be that the broadest range of interface types would be the > > > default. There are 2 UARTs exposed so I would have picked 1 to be > > > enabled by default. After that, with I2C and SPI enabled, there > > > are still 6 GPIO available. For a tiny board like this that seems > > > to be reasonable. If people have a need for slightly more GPIO > > > then I would expect they would be the ones configuring overlays. > > > > > > Apparently the developers of the Linux packages for these boards > > > have chosen the diverse approach (???FriendlyCore??? based on > > > UbuntuCore Xenial). > > > > > > IMHO, most ???hobbyists??? would prefer the diversity approach. > > > I???m completely capable of becoming an expert in FBSD and this > > > sort of configuration stuff yet it isn???t a priority for me - I > > > just want to use it like any other hobbyist. The way things are > > > now pushes this type of user away from FBSD. > > > > > > If there is some philosophical perspective against the diversity > > > approach then the next best thing is to have documentation that > > > clearly and simply tells people how to enable the other > > > functionality. > > > > > > Finally, I think there is an opportunity to grow FBSD in the > > > hobbyist world of these small products. We are past the point > > > where people can have a real operating system running on systems > > > at Arduino size and cost. Linux has been aggressively deployed > > > there but I can say from experience that it ain???t pretty - I > > > won???t say more as everyone reading this has a clear > > > understanding of why that is. > > > > I'm currently working an issue similar to this, but one that rates > > "highly annoying" right now rather than "catastrophically bad." > > > > The environment is a RPI2 which has GPIO and I2c configured; GPIO > > to > > drive outputs, I2c is used to read analog channels. > > > > On 11.0 this code ran perfectly well. > > > > On 12-STABLE )FreeBSD 12.0-STABLE r344818 GENERIC) > > it also runs well *BUT* generates a huge number of console > > messages > > about spurious interrupts: > > > > intc0: Spurious interrupt detected > > local_intc0: Spurious interrupt detected > > intc0: Spurious interrupt detected > > intc0: Spurious interrupt detected > > local_intc0: Spurious interrupt detected > > local_intc0: Spurious interrupt detected > > > > .... > > > > The issue is coming from the i2c side as I have another one of > > these > > that has no I2c defined in the configuration (but is running > > identical > > code) and no messages. > > Interesting. > A local Pi1 running 12-RELEASE has the same messages: > intc0: Spurious interrupt detected > intc0: Spurious interrupt detected > intc0: Spurious interrupt detected > intc0: Spurious interrupt detected > intc0: Spurious interrupt detected > intc0: Spurious interrupt detected > intc0: Spurious interrupt detected > I have an I2C RTC on this machine. > Hmmm, I can't reproduce this. I've got an rpi-b rev2 and I tried 13- current and the official 12.0-RELEASE image and I have no problems with interrupts while using an i2c RTC. I also connected an at24c512 eeprom and did a bunch of reading and writing to it. No spurious interrupts, and vmstat -i showed a completely reasonable number: intc0,61: iichb0 5652 23 I don't know what to try next. -- Ian From owner-freebsd-arm@freebsd.org Mon Mar 25 08:19:08 2019 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 B009F155670D for ; Mon, 25 Mar 2019 08:19:08 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4679E85FEA for ; Mon, 25 Mar 2019 08:19:08 +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 707BF17AED for ; Mon, 25 Mar 2019 08:19:07 +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 x2P8J7dE006244 for ; Mon, 25 Mar 2019 08:19:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2P8J78k006243 for freebsd-arm@FreeBSD.org; Mon, 25 Mar 2019 08:19:07 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 236772] build error on cross compile Date: Mon, 25 Mar 2019 08:19:07 +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: yamori813@yahoo.co.jp 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.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 08:19:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236772 Bug ID: 236772 Summary: build error on cross compile Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: yamori813@yahoo.co.jp I build sys/arm/ralink(armv5t) on amd64 host. I have build error on buildwo= rld after clang update 7.0. Now clang is 8.0. I have still error. One is this. -------------------------------------------------------------- >>> stage 3: cross tools -------------------------------------------------------------- ... =3D=3D=3D> lib/clang/headers (install) sh /usr/home/hiroki/freebsd/tools/install.sh -C -o root -g wheel -m 444=20 /usr/h ome/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/__clang_cuda_builti= n_var s.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/__clang_cuda_c math.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/__clang_cud a_complex_builtins.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Heade rs/__clang_cuda_device_functions.h /usr/home/hiroki/freebsd/contrib/llvm/tools/c lang/lib/Headers/__clang_cuda_intrinsics.h /usr/home/hiroki/freebsd/contrib/llvm /tools/clang/lib/Headers/__clang_cuda_libdevice_declares.h /usr/home/hiroki/free bsd/contrib/llvm/tools/clang/lib/Headers/__clang_cuda_math_forward_declares= .h /u sr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/__clang_cuda_ru= ntime _wrapper.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/__stdde f_max_align_t.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/__ wmmintrin_aes.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/__ wmmintrin_pclmul.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers /adxintrin.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/altiv ec.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/ammintri= n.h / usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/arm64intr.h /usr/ho me/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/arm_acle.h /usr/home/hiro ki/freebsd/contrib/llvm/tools/clang/lib/Headers/armintr.h /usr/home/hiroki/freeb sd/contrib/llvm/tools/clang/lib/Headers/avx2intrin.h /usr/home/hiroki/freebsd/co ntrib/llvm/tools/clang/lib/Headers/avx512bitalgintrin.h /usr/home/hiroki/freebsd /contrib/llvm/tools/clang/lib/Headers/avx512bwintrin.h /usr/home/hiroki/freebsd/ contrib/llvm/tools/clang/lib/Headers/avx512cdintrin.h /usr/home/hiroki/freebsd/c ontrib/llvm/tools/clang/lib/Headers/avx512dqintrin.h /usr/home/hiroki/freebsd/co ntrib/llvm/tools/clang/lib/Headers/avx512erintrin.h /usr/home/hiroki/freebsd/con trib/llvm/tools/clang/lib/Headers/avx512fintrin.h /usr/home/hiroki/freebsd/contr ib/llvm/tools/clang/lib/Headers/avx512ifmaintrin.h /usr/home/hiroki/freebsd/cont rib/llvm/tools/clang/lib/Headers/avx512ifmavlintrin.h /usr/home/hiroki/freebsd/c ontrib/llvm/tools/clang/lib/Headers/avx512pfintrin.h /usr/home/hiroki/freebsd/co ntrib/llvm/tools/clang/lib/Headers/avx512vbmi2intrin.h /usr/home/hiroki/freebsd/ contrib/llvm/tools/clang/lib/Headers/avx512vbmiintrin.h /usr/home/hiroki/freebsd /contrib/llvm/tools/clang/lib/Headers/avx512vbmivlintrin.h /usr/home/hiroki/free bsd/contrib/llvm/tools/clang/lib/Headers/avx512vlbitalgintrin.h /usr/home/hiroki /freebsd/contrib/llvm/tools/clang/lib/Headers/avx512vlbwintrin.h /usr/home/hirok i/freebsd/contrib/llvm/tools/clang/lib/Headers/avx512vlcdintrin.h /usr/home/hiro ki/freebsd/contrib/llvm/tools/clang/lib/Headers/avx512vldqintrin.h /usr/home/hir oki/freebsd/contrib/llvm/tools/clang/lib/Headers/avx512vlintrin.h /usr/home/hiro ki/freebsd/contrib/llvm/tools/clang/lib/Headers/avx512vlvbmi2intrin.h /usr/home/ hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/avx512vlvnniintrin.h /usr/ho me/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/avx512vnniintrin.h /usr/h ome/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/avx512vpopcntdqintr= in.h=20 /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/avx512vpopcnt= dqvli ntrin.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/avxintrin. h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/bmi2intrin.h /us r/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/bmiintrin.h /usr/home /hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/cetintrin.h /usr/home/hirok i/freebsd/contrib/llvm/tools/clang/lib/Headers/cldemoteintrin.h /usr/home/hiroki /freebsd/contrib/llvm/tools/clang/lib/Headers/clflushoptintrin.h /usr/home/hirok i/freebsd/contrib/llvm/tools/clang/lib/Headers/clwbintrin.h /usr/home/hiroki/fre ebsd/contrib/llvm/tools/clang/lib/Headers/clzerointrin.h /usr/home/hiroki/freebs d/contrib/llvm/tools/clang/lib/Headers/cpuid.h /usr/home/hiroki/freebsd/contrib/ llvm/tools/clang/lib/Headers/emmintrin.h /usr/home/hiroki/freebsd/contrib/llvm/t ools/clang/lib/Headers/f16cintrin.h /usr/home/hiroki/freebsd/contrib/llvm/tools/ clang/lib/Headers/fma4intrin.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang /lib/Headers/fmaintrin.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/H eaders/fxsrintrin.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Header s/gfniintrin.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/htm intrin.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/htmxlintr in.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/ia32intr= in.h=20 /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/immintrin.h /usr/h ome/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/invpcidintrin.h /usr/hom e/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/lwpintrin.h /usr/home/hiro ki/freebsd/contrib/llvm/tools/clang/lib/Headers/lzcntintrin.h /usr/home/hiroki/f reebsd/contrib/llvm/tools/clang/lib/Headers/mm3dnow.h /usr/home/hiroki/freebsd/c ontrib/llvm/tools/clang/lib/Headers/mm_malloc.h /usr/home/hiroki/freebsd/contrib /llvm/tools/clang/lib/Headers/mmintrin.h /usr/home/hiroki/freebsd/contrib/llvm/t ools/clang/lib/Headers/module.modulemap /usr/home/hiroki/freebsd/contrib/llvm/to ols/clang/lib/Headers/movdirintrin.h /usr/home/hiroki/freebsd/contrib/llvm/tools /clang/lib/Headers/msa.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/H eaders/mwaitxintrin.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Head ers/nmmintrin.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/op encl-c.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/pconfigin trin.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/pkuintrin.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/pmmintrin.h /usr/ home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/popcntintrin.h /usr/hom e/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/prfchwintrin.h /usr/home/h iroki/freebsd/contrib/llvm/tools/clang/lib/Headers/ptwriteintrin.h /usr/home/hir oki/freebsd/contrib/llvm/tools/clang/lib/Headers/rdseedintrin.h /usr/home/hiroki /freebsd/contrib/llvm/tools/clang/lib/Headers/rtmintrin.h /usr/home/hiroki/freeb sd/contrib/llvm/tools/clang/lib/Headers/s390intrin.h /usr/home/hiroki/freebsd/co ntrib/llvm/tools/clang/lib/Headers/sgxintrin.h /usr/home/hiroki/freebsd/contrib/ llvm/tools/clang/lib/Headers/shaintrin.h /usr/home/hiroki/freebsd/contrib/llvm/t ools/clang/lib/Headers/smmintrin.h /usr/home/hiroki/freebsd/contrib/llvm/tools/c lang/lib/Headers/tbmintrin.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/l ib/Headers/tmmintrin.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Hea ders/vadefs.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/vaes intrin.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/vecintrin .h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/vpclmulqdqint= ri n.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/waitpkgintrin. h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/wbnoinvdintri= n.h /usr/home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/wmmintrin.h /usr/ home/hiroki/freebsd/contrib/llvm/tools/clang/lib/Headers/x86intrin.h /usr/home/h iroki/freebsd/contrib/llvm/tools/clang/lib/Headers/xmmintrin.h /usr/home/hiroki/ freebsd/contrib/llvm/tools/clang/lib/Headers/xopintrin.h /usr/home/hiroki/freebs d/contrib/llvm/tools/clang/lib/Headers/xsavecintrin.h /usr/home/hiroki/freebsd/c ontrib/llvm/tools/clang/lib/Headers/xsaveintrin.h /usr/home/hiroki/freebsd/contr ib/llvm/tools/clang/lib/Headers/xsaveoptintrin.h /usr/home/hiroki/freebsd/contri b/llvm/tools/clang/lib/Headers/xsavesintrin.h /usr/home/hiroki/freebsd/contrib/l lvm/tools/clang/lib/Headers/xtestintrin.h arm_fp16.h arm_neon.h /usr/home/hiroki /zobj/usr/home/hiroki/ZRouter/tmp/usr/home/hiroki/freebsd/arm.arm/tmp/usr/l= ib/cl ang/8.0.0/include/ install: target directory `/usr/home/hiroki/zobj/usr/home/hiroki/ZRouter/tmp/usr /home/hiroki/freebsd/arm.arm/tmp/usr/lib/clang/8.0.0/include/' does not exi= st and other is this. -------------------------------------------------------------- >>> stage 4.1: building includes -------------------------------------------------------------- ... =3D=3D=3D> lib/libc++ (includes) sh /usr/home/hiroki/freebsd/tools/install.sh -C -o root -g wheel -m 444=20 /usr/h ome/hiroki/freebsd/contrib/libc++/include/__bit_reference /usr/home/hiroki/freeb sd/contrib/libc++/include/__bsd_locale_defaults.h /usr/home/hiroki/freebsd/contr ib/libc++/include/__bsd_locale_fallbacks.h /usr/home/hiroki/freebsd/contrib/libc ++/include/__config /usr/home/hiroki/freebsd/contrib/libc++/include/__debug /usr /home/hiroki/freebsd/contrib/libc++/include/__errc /usr/home/hiroki/freebsd/cont rib/libc++/include/__functional_03 /usr/home/hiroki/freebsd/contrib/libc++/inclu de/__functional_base /usr/home/hiroki/freebsd/contrib/libc++/include/__functiona l_base_03 /usr/home/hiroki/freebsd/contrib/libc++/include/__hash_table /usr/home /hiroki/freebsd/contrib/libc++/include/__libcpp_version /usr/home/hiroki/freebsd /contrib/libc++/include/__locale /usr/home/hiroki/freebsd/contrib/libc++/include /__mutex_base /usr/home/hiroki/freebsd/contrib/libc++/include/__node_handle /usr /home/hiroki/freebsd/contrib/libc++/include/__nullptr /usr/home/hiroki/freebsd/c ontrib/libc++/include/__split_buffer /usr/home/hiroki/freebsd/contrib/libc++/inc lude/__sso_allocator /usr/home/hiroki/freebsd/contrib/libc++/include/__std_strea m /usr/home/hiroki/freebsd/contrib/libc++/include/__string /usr/home/hiroki/free bsd/contrib/libc++/include/__threading_support /usr/home/hiroki/freebsd/contrib/ libc++/include/__tree /usr/home/hiroki/freebsd/contrib/libc++/include/__tup= le /u sr/home/hiroki/freebsd/contrib/libc++/include/__undef_macros /usr/home/hiroki/fr eebsd/contrib/libc++/include/algorithm /usr/home/hiroki/freebsd/contrib/libc++/i nclude/any /usr/home/hiroki/freebsd/contrib/libc++/include/array /usr/home/hirok i/freebsd/contrib/libc++/include/atomic /usr/home/hiroki/freebsd/contrib/libc++/ include/bit /usr/home/hiroki/freebsd/contrib/libc++/include/bitset /usr/home/hir oki/freebsd/contrib/libc++/include/cassert /usr/home/hiroki/freebsd/contrib/libc ++/include/ccomplex /usr/home/hiroki/freebsd/contrib/libc++/include/cctype /usr/ home/hiroki/freebsd/contrib/libc++/include/cerrno /usr/home/hiroki/freebsd/contr ib/libc++/include/cfenv /usr/home/hiroki/freebsd/contrib/libc++/include/cfl= oat / usr/home/hiroki/freebsd/contrib/libc++/include/charconv /usr/home/hiroki/freebsd /contrib/libc++/include/chrono /usr/home/hiroki/freebsd/contrib/libc++/include/c inttypes /usr/home/hiroki/freebsd/contrib/libc++/include/ciso646 /usr/home/hirok i/freebsd/contrib/libc++/include/climits /usr/home/hiroki/freebsd/contrib/libc++ /include/clocale /usr/home/hiroki/freebsd/contrib/libc++/include/cmath /usr/home /hiroki/freebsd/contrib/libc++/include/codecvt /usr/home/hiroki/freebsd/contrib/ libc++/include/compare /usr/home/hiroki/freebsd/contrib/libc++/include/comp= lex / usr/home/hiroki/freebsd/contrib/libc++/include/complex.h /usr/home/hiroki/freebs d/contrib/libc++/include/condition_variable /usr/home/hiroki/freebsd/contrib/lib c++/include/csetjmp /usr/home/hiroki/freebsd/contrib/libc++/include/csignal /usr /home/hiroki/freebsd/contrib/libc++/include/cstdarg /usr/home/hiroki/freebsd/con trib/libc++/include/cstdbool /usr/home/hiroki/freebsd/contrib/libc++/include/cst ddef /usr/home/hiroki/freebsd/contrib/libc++/include/cstdint /usr/home/hiroki/fr eebsd/contrib/libc++/include/cstdio /usr/home/hiroki/freebsd/contrib/libc++/incl ude/cstdlib /usr/home/hiroki/freebsd/contrib/libc++/include/cstring /usr/home/hi roki/freebsd/contrib/libc++/include/ctgmath /usr/home/hiroki/freebsd/contrib/lib c++/include/ctime /usr/home/hiroki/freebsd/contrib/libc++/include/ctype.h /usr/h ome/hiroki/freebsd/contrib/libc++/include/cwchar /usr/home/hiroki/freebsd/contri b/libc++/include/cwctype /usr/home/hiroki/freebsd/contrib/libc++/include/de= que / usr/home/hiroki/freebsd/contrib/libc++/include/errno.h /usr/home/hiroki/freebsd/ contrib/libc++/include/exception /usr/home/hiroki/freebsd/contrib/libc++/include /filesystem /usr/home/hiroki/freebsd/contrib/libc++/include/float.h /usr/home/hi roki/freebsd/contrib/libc++/include/forward_list /usr/home/hiroki/freebsd/contri b/libc++/include/fstream /usr/home/hiroki/freebsd/contrib/libc++/include/functio nal /usr/home/hiroki/freebsd/contrib/libc++/include/future /usr/home/hiroki/free bsd/contrib/libc++/include/initializer_list /usr/home/hiroki/freebsd/contrib/lib c++/include/inttypes.h /usr/home/hiroki/freebsd/contrib/libc++/include/ioma= nip / usr/home/hiroki/freebsd/contrib/libc++/include/ios /usr/home/hiroki/freebsd/cont rib/libc++/include/iosfwd /usr/home/hiroki/freebsd/contrib/libc++/include/iostre am /usr/home/hiroki/freebsd/contrib/libc++/include/istream /usr/home/hiroki/free bsd/contrib/libc++/include/iterator /usr/home/hiroki/freebsd/contrib/libc++/incl ude/limits /usr/home/hiroki/freebsd/contrib/libc++/include/limits.h /usr/home/hi roki/freebsd/contrib/libc++/include/list /usr/home/hiroki/freebsd/contrib/libc++ /include/locale /usr/home/hiroki/freebsd/contrib/libc++/include/locale.h /usr/ho me/hiroki/freebsd/contrib/libc++/include/map /usr/home/hiroki/freebsd/contrib/li bc++/include/math.h /usr/home/hiroki/freebsd/contrib/libc++/include/memory /usr/ home/hiroki/freebsd/contrib/libc++/include/mutex /usr/home/hiroki/freebsd/contri b/libc++/include/new /usr/home/hiroki/freebsd/contrib/libc++/include/numeric /us r/home/hiroki/freebsd/contrib/libc++/include/optional /usr/home/hiroki/freebsd/c ontrib/libc++/include/ostream /usr/home/hiroki/freebsd/contrib/libc++/include/qu eue /usr/home/hiroki/freebsd/contrib/libc++/include/random /usr/home/hiroki/free bsd/contrib/libc++/include/ratio /usr/home/hiroki/freebsd/contrib/libc++/include /regex /usr/home/hiroki/freebsd/contrib/libc++/include/scoped_allocator /usr/hom e/hiroki/freebsd/contrib/libc++/include/set /usr/home/hiroki/freebsd/contrib/lib c++/include/setjmp.h /usr/home/hiroki/freebsd/contrib/libc++/include/shared_mute x /usr/home/hiroki/freebsd/contrib/libc++/include/span /usr/home/hiroki/freebsd/ contrib/libc++/include/sstream /usr/home/hiroki/freebsd/contrib/libc++/include/s tack /usr/home/hiroki/freebsd/contrib/libc++/include/stdbool.h /usr/home/hiroki/ freebsd/contrib/libc++/include/stddef.h /usr/home/hiroki/freebsd/contrib/libc++/ include/stdexcept /usr/home/hiroki/freebsd/contrib/libc++/include/stdint.h /usr/ home/hiroki/freebsd/contrib/libc++/include/stdio.h /usr/home/hiroki/freebsd/cont rib/libc++/include/stdlib.h /usr/home/hiroki/freebsd/contrib/libc++/include/stre ambuf /usr/home/hiroki/freebsd/contrib/libc++/include/string /usr/home/hiroki/fr eebsd/contrib/libc++/include/string.h /usr/home/hiroki/freebsd/contrib/libc++/in clude/string_view /usr/home/hiroki/freebsd/contrib/libc++/include/strstream /usr /home/hiroki/freebsd/contrib/libc++/include/system_error /usr/home/hiroki/freebs d/contrib/libc++/include/tgmath.h /usr/home/hiroki/freebsd/contrib/libc++/includ e/thread /usr/home/hiroki/freebsd/contrib/libc++/include/tuple /usr/home/hiroki/ freebsd/contrib/libc++/include/type_traits /usr/home/hiroki/freebsd/contrib/libc ++/include/typeindex /usr/home/hiroki/freebsd/contrib/libc++/include/typein= fo /u sr/home/hiroki/freebsd/contrib/libc++/include/unordered_map /usr/home/hiroki/fre ebsd/contrib/libc++/include/unordered_set /usr/home/hiroki/freebsd/contrib/libc+ +/include/utility /usr/home/hiroki/freebsd/contrib/libc++/include/valarray /usr/ home/hiroki/freebsd/contrib/libc++/include/variant /usr/home/hiroki/freebsd/cont rib/libc++/include/vector /usr/home/hiroki/freebsd/contrib/libc++/include/versio n /usr/home/hiroki/freebsd/contrib/libc++/include/wchar.h /usr/home/hiroki/freeb sd/contrib/libc++/include/wctype.h /usr/home/hiroki/freebsd/contrib/libcxxrt/cxx abi.h /usr/home/hiroki/freebsd/contrib/libcxxrt/unwind-arm.h /usr/home/hiroki/fr eebsd/contrib/libcxxrt/unwind-itanium.h /usr/home/hiroki/freebsd/contrib/libcxxr t/unwind.h /usr/home/hiroki/zobj/usr/home/hiroki/ZRouter/tmp/usr/home/hiroki/fre ebsd/arm.arm/tmp/usr/include/c++/v1/ sh /usr/home/hiroki/freebsd/tools/install.sh -C -o root -g wheel -m 444=20 /usr/h ome/hiroki/freebsd/contrib/libc++/include/experimental/__config /usr/home/hiroki /freebsd/contrib/libc++/include/experimental/__memory /usr/home/hiroki/freebsd/c ontrib/libc++/include/experimental/algorithm /usr/home/hiroki/freebsd/contrib/li bc++/include/experimental/any /usr/home/hiroki/freebsd/contrib/libc++/include/ex perimental/chrono /usr/home/hiroki/freebsd/contrib/libc++/include/experimental/c oroutine /usr/home/hiroki/freebsd/contrib/libc++/include/experimental/deque /usr /home/hiroki/freebsd/contrib/libc++/include/experimental/filesystem /usr/home/hi roki/freebsd/contrib/libc++/include/experimental/forward_list /usr/home/hiroki/f reebsd/contrib/libc++/include/experimental/functional /usr/home/hiroki/freebsd/c ontrib/libc++/include/experimental/iterator /usr/home/hiroki/freebsd/contrib/lib c++/include/experimental/list /usr/home/hiroki/freebsd/contrib/libc++/include/ex perimental/map /usr/home/hiroki/freebsd/contrib/libc++/include/experimental/memo ry_resource /usr/home/hiroki/freebsd/contrib/libc++/include/experimental/numeric /usr/home/hiroki/freebsd/contrib/libc++/include/experimental/optional /usr/home /hiroki/freebsd/contrib/libc++/include/experimental/propagate_const /usr/home/hi roki/freebsd/contrib/libc++/include/experimental/ratio /usr/home/hiroki/freebsd/ contrib/libc++/include/experimental/regex /usr/home/hiroki/freebsd/contrib/libc+ +/include/experimental/set /usr/home/hiroki/freebsd/contrib/libc++/include/exper imental/simd /usr/home/hiroki/freebsd/contrib/libc++/include/experimental/string /usr/home/hiroki/freebsd/contrib/libc++/include/experimental/string_view /usr/h ome/hiroki/freebsd/contrib/libc++/include/experimental/system_error /usr/home/hi roki/freebsd/contrib/libc++/include/experimental/tuple /usr/home/hiroki/freebsd/ contrib/libc++/include/experimental/type_traits /usr/home/hiroki/freebsd/contrib /libc++/include/experimental/unordered_map /usr/home/hiroki/freebsd/contrib/libc ++/include/experimental/unordered_set /usr/home/hiroki/freebsd/contrib/libc++/in clude/experimental/utility /usr/home/hiroki/freebsd/contrib/libc++/include/exper imental/vector /usr/home/hiroki/zobj/usr/home/hiroki/ZRouter/tmp/usr/home/hiroki /freebsd/arm.arm/tmp/usr/include/c++/v1/experimental/ install: target directory `/usr/home/hiroki/zobj/usr/home/hiroki/ZRouter/tmp/usr /home/hiroki/freebsd/arm.arm/tmp/usr/include/c++/v1/experimental/' does not exis t --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Mar 25 08:44:43 2019 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 C23C315574FB for ; Mon, 25 Mar 2019 08:44:42 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh604-vm9.bullet.mail.ssk.yahoo.co.jp (nh604-vm9.bullet.mail.ssk.yahoo.co.jp [182.22.90.66]) by mx1.freebsd.org (Postfix) with SMTP id EB89F87006 for ; Mon, 25 Mar 2019 08:44:33 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [182.22.66.105] by nh604.bullet.mail.ssk.yahoo.co.jp with NNFMP; 25 Mar 2019 08:42:47 -0000 Received: from [182.22.91.132] by t603.bullet.mail.ssk.yahoo.co.jp with NNFMP; 25 Mar 2019 08:42:47 -0000 Received: from [127.0.0.1] by omp605.mail.ssk.yahoo.co.jp with NNFMP; 25 Mar 2019 08:42:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 390062.40702.bm@omp605.mail.ssk.yahoo.co.jp X-YMail-OSG: bfps4aIVM1mTWqgreFycGmae9HvCjWQyc2B6sLzukooO8vfARAvWiN_B7YtWlEq Xy44Rol7KbYt7hrfBY8zkHTOkVNpdzT7ULnrtMWMYEp5hfxG3rPdsdX2IRZOOsJ0ZTHdANIsTasq nJeviR2176fn03bP0QBc6p1dAGP7o9oWSgXT7ftkYU68pNRuPYfuVx5ki2YgC6BAwb99vb4o8Ijw I_9hB98oFyFDAJAsxAH4.1AflUIbvftJ0rXicN9H5y5HvbEG5Q6S4wAjZmsIbVOKOgZg5IgdllxK SQlYbmaVMmvs8dJ71RTVNlGm6Hgq243ifdjGZFz1DALPvLMiPu9qqSapsDF3VR6aQPCsASEgyljr xIujW4.i8MUJFt7UnmsbG6lI4CxBhHTcluLqQCKkjoRy9BuxdfCDo8ILqlJoxpWJk8DOS_GCJdO. rqEYfEZ0MLlz7qzzGYmGDPxIRVa3ewoXkOLlnyo1L5JG1MdORrAMKqLZygQ8kT7jDgAkp69bgqmW fYwOqpWYBFncrpyDNZh6EBZcvoOvyRNcryeOs2UECQumgSomcuajN97D_67fnr9XLzNyLyUERkjc cGfp_3bMT4P1gY3tag3Tvk.t2OgwXIdV7yGsdwq4s Received: from jws700001.mail.kks.yahoo.co.jp by sendmailws508.mail.kks.yahoo.co.jp; Mon, 25 Mar 2019 17:42:46 +0000; 1553503366.752 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1553503367; s=yj20110701; d=yahoo.co.jp; h=Date:From:Reply-To:To:Cc:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=KNAJiFXe9dzl39M3BJa9MGv1CDgQjMjoWHWoeO/AJe4=; b=AktmRektN29lNzXgJTvlU9NTX5fWEoBZ5VTk/y3F9UyEBss41gqdhC1ARmCacqmn zo6ONbyt9ezLHFpZna93LYk7LC8km58Pr16dyQY5v9kLJCbxtRrntI3KH1aZzfEgolV AG/kfpCHTf1Qta0RLrTcFfn+qkgtmVtTZLAL0Y9I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Date:From:Reply-To:Cc:Message-ID:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HVC+Lu2fZwS+uozwes2uYHi7IEflHwFG+L2BmK+H1t3oKLcZUnu+UpAipEoy7BEN BMBB5Fc6NrLqeQt8dgBL608mNJRAn176DuaS0+yYJLUavY9Sho3ZKYolQhpSgkfxH7q 7U3asZ0VQ7QdhsWAIS7CKukyBnwGah/QFOoUAhDU=; Date: Mon, 25 Mar 2019 17:42:46 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki To: Warner Losh Cc: "freebsd-arm@freebsd.org" Message-ID: <1779274200.1171387.1553503366347.JavaMail.yahoo@mail.yahoo.co.jp> In-Reply-To: References: <188467496.378105.1553363991969.JavaMail.yahoo.ref@mail.yahoo.co.jp> <188467496.378105.1553363991969.JavaMail.yahoo@mail.yahoo.co.jp> Subject: Re: Ralink armv5t MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: EB89F87006 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.co.jp header.s=yj20110701 header.b=AktmRekt; dmarc=pass (policy=none) header.from=yahoo.co.jp; spf=pass (mx1.freebsd.org: domain of yamori813@yahoo.co.jp designates 182.22.90.66 as permitted sender) smtp.mailfrom=yamori813@yahoo.co.jp X-Spamd-Result: default: False [1.49 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[yamori813@yahoo.co.jp]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:182.22.90.0/23]; FREEMAIL_FROM(0.00)[yahoo.co.jp]; MX_GOOD(-0.01)[mx3.mail.yahoo.co.jp, mx1.mail.yahoo.co.jp, mx5.mail.yahoo.co.jp, mx2.mail.yahoo.co.jp, mx3.mail.yahoo.co.jp, mx1.mail.yahoo.co.jp, mx5.mail.yahoo.co.jp, mx2.mail.yahoo.co.jp, mx3.mail.yahoo.co.jp, mx1.mail.yahoo.co.jp, mx5.mail.yahoo.co.jp, mx2.mail.yahoo.co.jp, mx3.mail.yahoo.co.jp, mx1.mail.yahoo.co.jp, mx5.mail.yahoo.co.jp, mx2.mail.yahoo.co.jp, mx3.mail.yahoo.co.jp, mx1.mail.yahoo.co.jp, mx5.mail.yahoo.co.jp, mx2.mail.yahoo.co.jp, mx3.mail.yahoo.co.jp, mx1.mail.yahoo.co.jp, mx5.mail.yahoo.co.jp, mx2.mail.yahoo.co.jp, mx3.mail.yahoo.co.jp, mx1.mail.yahoo.co.jp, mx5.mail.yahoo.co.jp, mx2.mail.yahoo.co.jp, mx3.mail.yahoo.co.jp, mx1.mail.yahoo.co.jp, mx5.mail.yahoo.co.jp, mx2.mail.yahoo.co.jp, mx3.mail.yahoo.co.jp, mx1.mail.yahoo.co.jp, mx5.mail.yahoo.co.jp, mx2.mail.yahoo.co.jp, mx3.mail.yahoo.co.jp, mx1.mail.yahoo.co.jp, mx5.mail.yahoo.co.jp, mx2.mail.yahoo.co.jp, mx3.mail.yahoo.co.jp, mx1.mail.yahoo.co.jp, mx5.mail.yahoo.co.jp, mx2.mail.yahoo.co.jp, mx3.mail.yahoo.co.jp, mx1.mail.yahoo.co.jp, mx5.mail.yahoo. co.jp,mx2.mail.yahoo.co.jp,mx3.mail.yahoo.co.jp,mx1.mail.yahoo.co.jp,mx5.mail.yahoo.co.jp,mx2.mail.yahoo.co.jp,mx3.mail.yahoo.co.jp,mx1.mail.yahoo.co.jp,mx5.mail.yahoo.co.jp,mx2.mail.yahoo.co.jp,mx3.mail.yahoo.co.jp,mx1.mail.yahoo.co.jp,mx5.mail.yahoo.co.jp,mx2.mail.yahoo.co.jp,mx3.mail.yahoo.co.jp,mx1.mail.yahoo.co.jp,mx5.mail.yahoo.co.jp,mx2.mail.yahoo.co.jp,mx3.mail.yahoo.co.jp,mx1.mail.yahoo.co.jp,mx5.mail.yahoo.co.jp,mx2.mail.yahoo.co.jp,mx3.mail.yahoo.co.jp,mx1.mail.yahoo.co.jp,mx5.mail.yahoo.co.jp,mx2.mail.yahoo.co.jp,mx3.mail.yahoo.co.jp,mx1.mail.yahoo.co.jp,mx5.mail.yahoo.co.jp,mx2.mail.yahoo.co.jp,mx3.mail.yahoo.co.jp,mx1.mail.yahoo.co.jp,mx5.mail.yahoo.co.jp,mx2.mail.yahoo.co.jp,mx3.mail.yahoo.co.jp,mx1.mail.yahoo.co.jp,mx5.mail.yahoo.co.jp,mx2.mail.yahoo.co.jp]; DMARC_POLICY_ALLOW(-0.50)[yahoo.co.jp,none]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[yahoo.co.jp:+]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.co.jp]; ASN(0.00)[asn:23816, ipnet:182.22.0.0/17, country:JP]; IP_SCORE(0.92)[ipnet: 182.22.0.0/17(2.59), asn: 23816(2.08), country: JP(-0.07)]; DWL_DNSWL_NONE(0.00)[yahoo.co.jp.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.co.jp:s=yj20110701]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; NEURAL_SPAM_SHORT(0.75)[0.752,0]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[yahoo.co.jp]; NEURAL_SPAM_MEDIUM(0.59)[0.594,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.13)[0.131,0]; RCVD_IN_DNSWL_NONE(0.00)[66.90.22.182.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 08:44:43 -0000 Hi I think you can build freebsd master tree. I think your problem is address = or compress. ZRouter use old lzma command by ray's hack. This is my kernel elf infomation. % readelf -h Buffalo_WZR2-G300N_kernel ELF Header: =C2=A0 Magic:=C2=A0=C2=A0 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00= =20 =C2=A0 Class:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ELF32 =C2=A0 Data:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2's complement, little endian =C2=A0 Version:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 1 (current) =C2=A0 OS/ABI:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 FreeBSD =C2=A0 ABI Version:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 0 =C2=A0 Type:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EXEC (Executable file) =C2=A0 Machine:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ARM =C2=A0 Version:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 0x1 =C2=A0 Entry point address:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0xc0000100 =C2=A0 Start of program headers:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 52 (bytes into file) =C2=A0 Start of section headers:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 3628384 (bytes into file) =C2=A0 Flags:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x5000202, Version5 EABI, has entry point= ,=20 software FP =C2=A0 Size of this header:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 52 (bytes) =C2=A0 Size of program headers:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 32 (bytes) =C2=A0 Number of program headers:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 6 =C2=A0 Size of section headers:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 40 (bytes) =C2=A0 Number of section headers:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 38 =C2=A0 Section header string table index: 35 This is files information. Buffalo_WZR2-G300N_kernel:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ELF 32-bit LSB executable, AR M, EABI5 version 1 (FreeBSD), dynamically linked, interpreter /red/herring,= for=20 FreeBSD 13.0 (1300017), not stripped Buffalo_WZR2-G300N_kernel.kbin:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 da= ta Buffalo_WZR2-G300N_kernel.kbin.oldlzma:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LZMA compressed data, non-str eamed, size 2871992 Buffalo_WZR2-G300N_kernel.kbin.oldlzma.uboot:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= u-boot legacy uImage, FreeBSD =C2=A0Kernel Image, Linux/ARM, OS Kernel Image (lzma), 999733 bytes, Fri Ma= r 22 10:49 :29 2019, Load Address: 0x40000100, Entry Point: 0x40000100, Header CRC: 0x= 0DC80 973, Data CRC: 0xFCAD138A Thanks Hiroki Mori ----- Original Message ----- >From: Warner Losh >To: Mori Hiroki =20 >Cc: "freebsd-arm@freebsd.org" >Date: 2019/3/24, Sun 03:26 >Subject: Re: Ralink armv5t >=20 > >I'd love to get my ralink board going... I still haven't been able to get = it booting all the way... > > >Do I need to build with ZRouter? Or can I do that with just a plain FreeBS= D tree? I've been doing the latter, but I see from your dmesg postings that= maybe I should consider the former.... > > >Warner > >On Sat, Mar 23, 2019 at 11:59 AM Mori Hiroki wrote= : > >Hi >> >>I give WZR2-G300N to manu yesterday. >> >> >>Also I give WZR2-G300N to hrs and mizhka. >> >>Regards >> >>Hiroki Mori >> >> > > From owner-freebsd-arm@freebsd.org Mon Mar 25 10:06:12 2019 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 115E11559AB0 for ; Mon, 25 Mar 2019 10:06:12 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh602-vm2.bullet.mail.ssk.yahoo.co.jp (nh602-vm2.bullet.mail.ssk.yahoo.co.jp [182.22.90.27]) by mx1.freebsd.org (Postfix) with SMTP id 47E598A1D3 for ; Mon, 25 Mar 2019 10:06:07 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [182.22.66.104] by nh602.bullet.mail.ssk.yahoo.co.jp with NNFMP; 25 Mar 2019 10:05:59 -0000 Received: from [182.22.91.128] by t602.bullet.mail.ssk.yahoo.co.jp with NNFMP; 25 Mar 2019 10:05:59 -0000 Received: from [127.0.0.1] by omp601.mail.ssk.yahoo.co.jp with NNFMP; 25 Mar 2019 10:05:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 521141.94037.bm@omp601.mail.ssk.yahoo.co.jp X-YMail-OSG: do6kklkVM1lzNEGMykVDK.NOV3sUDyBrJe6PT6jv.qG14WJbQgW8KAoFoKbOto0 4L8RV4U8qCCEVvG0WIkWMo90XAaNhAYsGXjPKYytmJDmr3lWKkHYNAhu2ZOqq4oK8_XXeHdW5ZKa YsVc9Bhd5Xsr8pQXIAUbjV3Kg9wWLtWpWbGMWW04DvvcHyRn3tCxpzjG8tF8wIFEKtV1CcjHiUBk rxu7KtbRcjeUPz8G5sp6JxIHDvLyWsTyZCqiduNNjbb13N11DLYpfJWez9qX7YWAieTUX_hB1_sa DIXo1_9GVkrH63jE0.vr5IkdSA35hqS_J6NSFIFkz0_buhHjnPjpzQU1nO.nyBEepUXp3ozOd0dq CoJKBf7VGMw0Cd4bj9jm85M.mb_semDPnZgV9bEyszgFcm07vdnArYS7YT1odGS36jSI76ripBh9 bOqu3fcKcGCHDQFXxZGF.QLmNqNbczKnjmdwzXK1pEA8n9qiLUrEV2YdtEE6C6axuweP0M24FyDm Knd_a9D5Sja_qW.T7y6d2tOazmQjnDBki2c6_6bXHsoXQV5.oJTaD4goKRJVSzh82Sa_GAqaxAvL rP4qCVnTy7CthltC6zs4LUU00KxxP8uRw_urEeJ9G Received: from jws701106.mail.ssk.yahoo.co.jp by sendmailws615.mail.ssk.yahoo.co.jp; Mon, 25 Mar 2019 19:05:58 +0000; 1553508358.915 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1553508359; s=yj20110701; d=yahoo.co.jp; h=Date:From:Reply-To:To:Cc:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=mpdsAfT1G5xkQ6/48odF081ZQyl5eZr7D3Z0t4R3/e4=; b=p+Il5XRU72LLBOfUH2cHAtUcH0nBAiv3sGVcPh5AQurYSai2tKm7oBi+CHygmPfn kdGul+YvXiIs/CpAPuEw7O6jN9JoTf3pEn/uErOK6ilp/LIUpHs0RO9+dl2Yp72xJFj UaItUeWdMZglh/xgx8JWDXf4WMhgSZBbb6inu0fA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Date:From:Reply-To:Cc:Message-ID:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PWb+uDmCLMwcXo12eJ+qNJnEkVPzVFG/VEcrqCaHUMesWJObw/L2fLPkNdLxfHYy r/sND4EFwHELZGN+EDZw1yAXpmNtM+6py6F27gFZINIzhofIC8gAZll5o3jiQTPTXeG nsU3DMpqWw6G/g1UIltj7RdjeGJuSYnAdmjuytHA=; Date: Mon, 25 Mar 2019 19:05:58 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki To: Warner Losh Cc: "freebsd-arm@freebsd.org" Message-ID: <1962304113.475158.1553508358133.JavaMail.yahoo@mail.yahoo.co.jp> In-Reply-To: <1779274200.1171387.1553503366347.JavaMail.yahoo@mail.yahoo.co.jp> References: <188467496.378105.1553363991969.JavaMail.yahoo.ref@mail.yahoo.co.jp> <188467496.378105.1553363991969.JavaMail.yahoo@mail.yahoo.co.jp> <1779274200.1171387.1553503366347.JavaMail.yahoo@mail.yahoo.co.jp> Subject: Re: Ralink armv5t MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 47E598A1D3 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.co.jp header.s=yj20110701 header.b=p+Il5XRU; dmarc=pass (policy=none) header.from=yahoo.co.jp; spf=pass (mx1.freebsd.org: domain of yamori813@yahoo.co.jp designates 182.22.90.27 as permitted sender) smtp.mailfrom=yamori813@yahoo.co.jp X-Spamd-Result: default: False [0.30 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[yamori813@yahoo.co.jp]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:182.22.90.0/23]; FREEMAIL_FROM(0.00)[yahoo.co.jp]; DKIM_TRACE(0.00)[yahoo.co.jp:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.co.jp,none]; RCPT_COUNT_TWO(0.00)[2]; MX_GOOD(-0.01)[cached: mx3.mail.yahoo.co.jp]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.co.jp]; ASN(0.00)[asn:23816, ipnet:182.22.0.0/17, country:JP]; IP_SCORE(0.91)[ipnet: 182.22.0.0/17(2.58), asn: 23816(2.06), country: JP(-0.07)]; DWL_DNSWL_NONE(0.00)[yahoo.co.jp.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.co.jp:s=yj20110701]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; NEURAL_HAM_LONG(-0.70)[-0.698,0]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[yahoo.co.jp]; NEURAL_SPAM_MEDIUM(0.20)[0.198,0]; NEURAL_SPAM_SHORT(0.80)[0.800,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[27.90.22.182.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 10:06:12 -0000 Hi This is command of u-boot for execute kernel by tftp. 5VT1310-EVB# tftpboot 0x40800000 Buffalo_WZR2-G300N_kernel.kbin.oldlzma.ubo= ot 5VT1310-EVB# tftpboot $(memtmp_addr) Buffalo_WZR2-G300N_kernel.kbin.oldlzma= .uboot 5VT1310-EVB# bootm Hiroki Mori ----- Original Message ----- > From: Mori Hiroki > To: Warner Losh > Cc: "freebsd-arm@freebsd.org" > Date: 2019/3/25, Mon 17:42 > Subject: Re: Ralink armv5t >=20 > Hi >=20 > I think you can build freebsd master tree. I think your problem is addres= s or=20 > compress. >=20 > ZRouter use old lzma command by ray's hack. >=20 >=20 > This is my kernel elf infomation. >=20 >=20 > % readelf -h Buffalo_WZR2-G300N_kernel > ELF Header: > =C2=A0 Magic:=C2=A0=C2=A0 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00= =20 > =C2=A0 Class:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ELF32 > =C2=A0 Data:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2's complement, little endian > =C2=A0 Version:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 1 (current) > =C2=A0 OS/ABI:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FreeBSD > =C2=A0 ABI Version:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 0 > =C2=A0 Type:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EXEC (Executable file) > =C2=A0 Machine:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ARM > =C2=A0 Version:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 0x1 > =C2=A0 Entry point address:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0xc0000100 > =C2=A0 Start of program headers:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 52 (bytes into file) > =C2=A0 Start of section headers:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 3628384 (bytes into file) > =C2=A0 Flags:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x5000202, Version5 EABI, has entry point= ,=20 > software FP > =C2=A0 Size of this header:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 52 (bytes) > =C2=A0 Size of program headers:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 32 (bytes) > =C2=A0 Number of program headers:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 6 > =C2=A0 Size of section headers:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 40 (bytes) > =C2=A0 Number of section headers:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 38 > =C2=A0 Section header string table index: 35 >=20 >=20 > This is files information. >=20 > Buffalo_WZR2-G300N_kernel:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ELF 32-bit LSB executable, AR > M, EABI5 version 1 (FreeBSD), dynamically linked, interpreter /red/herrin= g, for=20 > FreeBSD 13.0 (1300017), not stripped > Buffalo_WZR2-G300N_kernel.kbin:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 da= ta > Buffalo_WZR2-G300N_kernel.kbin.oldlzma:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LZMA compressed data, non-str > eamed, size 2871992 > Buffalo_WZR2-G300N_kernel.kbin.oldlzma.uboot:=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 u-boot legacy uImage, FreeBSD > =C2=A0Kernel Image, Linux/ARM, OS Kernel Image (lzma), 999733 bytes, Fri = Mar 22 10:49 > :29 2019, Load Address: 0x40000100, Entry Point: 0x40000100, Header CRC: = 0x0DC80 > 973, Data CRC: 0xFCAD138A >=20 > Thanks >=20 > Hiroki Mori >=20 >=20 > ----- Original Message ----- >> From: Warner Losh >> To: Mori Hiroki =20 >> Cc: "freebsd-arm@freebsd.org" >> Date: 2019/3/24, Sun 03:26 >> Subject: Re: Ralink armv5t >>=20 >>=20 >> I'd love to get my ralink board going... I still haven't been able=20 > to get it booting all the way... >>=20 >>=20 >> Do I need to build with ZRouter? Or can I do that with just a plain Free= BSD=20 > tree? I've been doing the latter, but I see from your dmesg postings that= =20 > maybe I should consider the former.... >>=20 >>=20 >> Warner >>=20 >> On Sat, Mar 23, 2019 at 11:59 AM Mori Hiroki =20 > wrote: >>=20 >> Hi >>>=20 >>> I give WZR2-G300N to manu yesterday. >>>=20 >>>=20 >>> Also I give WZR2-G300N to hrs and mizhka. >>>=20 >>> Regards >>>=20 >>> Hiroki Mori >>>=20 >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm=20 > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 From owner-freebsd-arm@freebsd.org Mon Mar 25 13:40:15 2019 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 B23671561AD0 for ; Mon, 25 Mar 2019 13:40:15 +0000 (UTC) (envelope-from sanpei.ml@gmail.com) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A77A46C336; Mon, 25 Mar 2019 13:40:14 +0000 (UTC) (envelope-from sanpei.ml@gmail.com) Received: by mail-pf1-x442.google.com with SMTP id i19so6470578pfd.0; Mon, 25 Mar 2019 06:40: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=B2lxOM6sACrwktTVubAuPqfMVFeetBndn1eV9pQU/jE=; b=W10N75PvNV1AJxKlMpLIDs8GXSgPjyzJf+4rks1CYDGEic7zczrTHmvoDhpiYSMSUB DdalNpaTSccHBUUTxz3YJrg0dYlSP+PqdOqS7Hna9RGgH3LDuEVDl/pAeZhn7tNhbXMF cGDSHRjHU2vWwanCFpJUhVSyKlhs+YXLdPjHhyC7yjDaxz9ZsSO7DarQx42JpR1ICw3J elPlqSbZU5BjkpGsxErMqyZf+wu6HN+bRqVJ6eaAzBbzVdXQS6mr2yzmi7MrilEpADGv MXTQUdW6sMmKPcfr3EJikH/BhhFpbINIlnh3IUGEFbBexzF8X3dwTn2PwgRrszLeOz0Q RjEw== 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=B2lxOM6sACrwktTVubAuPqfMVFeetBndn1eV9pQU/jE=; b=WQSVgbDpOVwPoifzS2n5w7g6LFDuL9LsftNGGJfQ3Jq6SQFeumwpOKss/6Bfccndiz nLTbcAVweaDODKMbwgK5pHM9uXwasm8PdSFGr4L7ErElxOrVTBjpdeasgmOJ/7I9WByi BfVCA2g40lZXDR1RuTA+/48XDbXWBN5W7eS2Y/x4z52k4HzGeGwUIziL62lmDM7DzuIc uaFaP/Y++LlskMaTWowrOPlfZN5Xr8H9ooNwDb+wMMqzxpwGvYk17Aj084AwhVsQ03DQ 6ztkUPaHZx+i4nt2dsm465izQiZhEUO10A57sbjhhrPhufVimA0McpGCoqrWirfYD6qK 0fdA== X-Gm-Message-State: APjAAAXC805CwVKvCzPojx2P6HJBpkjadpz+qBpIwrkKZuIZSQH8GdhZ 9EqleJI9byG3oKngukk5sNKsbDSDqoS9g+nj2Pa6At9g X-Google-Smtp-Source: APXvYqw7K/kEx7dk1jtGjY0XWZAZ95HcTx9W+2Wy20Gw2q1SfHmyxehtB7nBoSS6jhGoKuarsEIIqjEfiQcY8ydTSZA= X-Received: by 2002:a62:e502:: with SMTP id n2mr24386243pff.242.1553521213344; Mon, 25 Mar 2019 06:40:13 -0700 (PDT) MIME-Version: 1.0 References: <4f421a5f-c09d-46a4-8d45-4f7e5e3b2e40@Spark> <1545061176.76088.73.camel@freebsd.org> In-Reply-To: <1545061176.76088.73.camel@freebsd.org> From: Yoshiro MIHIRA Date: Mon, 25 Mar 2019 22:39:59 +0900 Message-ID: Subject: Re: FreeBSD-12.0-current not booting on hummingboard To: Ian Lepore Cc: =?UTF-8?Q?Radovan_P=C3=BAtec?= , freebsd-arm X-Rspamd-Queue-Id: A77A46C336 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=W10N75Pv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sanpeiml@gmail.com designates 2607:f8b0:4864:20::442 as permitted sender) smtp.mailfrom=sanpeiml@gmail.com X-Spamd-Result: default: False [-4.44 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[2.4.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.91)[-0.907,0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; IP_SCORE(-0.53)[ip: (2.43), ipnet: 2607:f8b0::/32(-2.86), asn: 15169(-2.14), country: US(-0.07)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 13:40:16 -0000 Hi all, I have Hummingboard-i2. I tested FreeBSD-12.0-RELEASE image. Unfortunately, I have two issues. 1) u-boot issue. Maybe latest u-boot does not support Hummingboard-i2. I use old u-boot which is included 11.0-RELEASE. >From sysutils/u-boot-cubox-hummingboard/pkg-descr: >As of this writing,the changes in this fork have not been rolled back into= upstream U-Boot. 2) GENERIC kernel issue GENERIC kernel could not boot[NG]. If I use IMX6 kernel config, I can boot it. boot messages as blow: https://www.sanpei.org/~sanpei/tmp/12.0-RELEASE-with-11.0-uboot-NG If I have time, I will try to find out the reason and to support GENERIC kernel on Hummingboard. Yours Yoshiro MIHIRA 2018=E5=B9=B412=E6=9C=8818=E6=97=A5(=E7=81=AB) 0:40 Ian Lepore : > On Sun, 2018-12-16 at 17:34 +0100, Radovan Ptec wrote: > > Hi there, > > > > I've tried installing FreeBSD-12.0-RELEASE on hummingboard, however > > it seems to > > be broken,same problem with RC3. Can't test with earlier RC as I > > didn=E2=80=99t > > downloaded one and I can=E2=80=99tfind them anymore. > > > > 11.2 armv6 is working as expected, upgrading to 12.0 from source as > > armv6 is > > also working asexpected. > > > > Sorry, no serial console available, I've managed to fry it some time > > ago. > > After connecting HDMI I see following output in loop (adresses > > change): > > > > pc : [<1792640c>] lr : [<4ff9f403>] > > reloc pc : [<1782640c>] lr : [<17826403>] > > sp : 4f672d08 ip : 4f59 fp : 4f5769dc > > r10: 4ffb3f02 r9 : 4f57 r8 : 4ff9f40c > > r7 : 4f89b250 r6 : 4f89 r5 : 4ffc10e r4 : ffffffff > > r3 : 9ff01ce5 r2 : 9ff0 r1 : 4ffb3f02 r0 : 0000005e > > Flags: nzCv IRQs on FIQs on Mode SVC_32 > > Code: f00968a0 b918f866 68e04641 ffb2f7ff (e7ef6824) > > data abort > > > > At this point I'm not sure how to proceed with adressing this issue, > > or how to debug > > the problem.Any hints? > > > > Thank you! > > radovan > > Nothing in freebsd creates output that looks like that. I think that > must be u-boot that is crashing and generating that report. But I don't > have anything useful to add beyond that observation. > > -- Ian > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Mon Mar 25 15:08:22 2019 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 EBF40156457F for ; Mon, 25 Mar 2019 15:08:21 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (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 F3A7B704C9; Mon, 25 Mar 2019 15:08:20 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1h8RD1-009S7U-5e; Mon, 25 Mar 2019 16:08:19 +0100 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 From: Ralf Wenk To: Ian Lepore cc: freebsd-arm@freebsd.org Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] In-reply-to: <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> References: <8df902f6-20a3-31c4-71ac-91f5d5fdf50d@optiplex-networks.com> <0ecf23e129ca7ac6a92a01bbb34c03f1ac8c6dc8.camel@freebsd.org> <89f5b8d1ab0614ac8d88b5d5f1afc63e640c3c17.camel@freebsd.org> <4EB5C6C1-7DB9-4DEE-BB23-CD1259581271@jeditekunum.com> <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> <20190319161423.GH57400@cicely7.cicely.de> <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Mar 2019 16:08:19 +0100 Message-Id: X-Rspamd-Queue-Id: F3A7B704C9 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.70 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[hs-karlsruhe.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.994,0]; IP_SCORE(0.33)[asn: 553(1.66), country: EU(-0.00)]; NEURAL_SPAM_SHORT(0.99)[0.991,0]; MX_GOOD(-0.01)[smtp.hs-karlsruhe.de]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[25.64.196.193.list.dnswl.org : 127.0.10.0]; NEURAL_SPAM_LONG(0.99)[0.993,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:553, ipnet:193.196.64.0/18, country:EU]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 15:08:22 -0000 On 2019-03-24 at 17:55 -0600 Ian Lepore wrote: > On Tue, 2019-03-19 at 17:14 +0100, Bernd Walter wrote: > > On Tue, Mar 19, 2019 at 09:55:12AM -0500, Karl Denninger wrote: > > > On 3/19/2019 09:26, Jedi Tek'Unum wrote: > > > > On Mar 18, 2019, at 2:57 PM, Ian Lepore wrote: > > > > > On Mon, 2019-03-18 at 14:51 -0500, Jedi Tek'Unum wrote: > > > > > > My impression wasn???t that support wasn???t there - but > > > > > > ???out of the box??? > > > > > > configuration wasn???t there. In comparison, I didn???t have > > > > > > to do > > > > > > anything to get I2C enabled in the binary distribution of > > > > > > Linux that > > > > > > comes through the manufacturer. > > > > > > > > > > > > Its the enabling part that isn???t obvious to most people > > > > > > IMO. > > > > > > > > > > > > Documentation/wiki is great. But even better would be all the > > > > > > enabling overlays already in place and the entries in > > > > > > loader.conf > > > > > > already there and commented out. It would be so much easier > > > > > > to go to > > > > > > a ???common place??? (loader.conf), skim through the notes, > > > > > > find the > > > > > > thing that one wants, and then just uncomment the referenced > > > > > > line! > > > > > > (Or any other similarly easy method.) > > > > > > > > > > > > > > > > > > For FBSD to get a better foothold in this space it needs to > > > > > > be better > > > > > > documented. For example, the wiki for NEO2 < > > > > > > http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2>; is a > > > > > > step-by- > > > > > > step guide for how to acquire and configure Linux for it. > > > > > > > > > > > > > > > > > > > > > > On one of my imx6 boards I have 5 SPI devices. Each device can > > > > > use 3 > > > > > or 4 different sets of pins for clock, data-in, and data- > > > > > out. Plus, > > > > > each can use literally any number of whatever gpio pins they > > > > > want as > > > > > chip selects. Even limiting the chipsels to a handfull, there > > > > > would > > > > > literally be thousands of possible combinations of devices and > > > > > pin > > > > > configurations, each one needing to be a separate overlay. > > > > > > > > > > Maybe you have experience primarily with rpi or some similarly > > > > > crippled > > > > > devices that only offer one or two choices? > > > > > > > > If memory serves correctly, there are only 2 I2C devices on the > > > > H3/H5 and the NanoPi NEO/2 implementations only externalize 1. > > > > There is only 1 SPI AFAIK. > > > > > > > > I wouldn???t call that crippled. I chose this platform exactly > > > > because of its characteristics - small, fast, cheap. It fits the > > > > project I???m using it for perfectly. In fact, I can see uses for > > > > even smaller (see Giant Board > > > >). I understand other projects may have different requirements > > > > and would drive one towards different solutions - and require > > > > more of the various interfaces. But they aren???t going to be > > > > typical of hobbyist projects. > > > > > > > > Maybe I should pose the question in another way. What is the > > > > philosophy for choosing GPIO as default for all the pins? These > > > > boards have a very limited number of pins and my preference would > > > > be that the broadest range of interface types would be the > > > > default. There are 2 UARTs exposed so I would have picked 1 to be > > > > enabled by default. After that, with I2C and SPI enabled, there > > > > are still 6 GPIO available. For a tiny board like this that seems > > > > to be reasonable. If people have a need for slightly more GPIO > > > > then I would expect they would be the ones configuring overlays. > > > > > > > > Apparently the developers of the Linux packages for these boards > > > > have chosen the diverse approach (???FriendlyCore??? based on > > > > UbuntuCore Xenial). > > > > > > > > IMHO, most ???hobbyists??? would prefer the diversity approach. > > > > I???m completely capable of becoming an expert in FBSD and this > > > > sort of configuration stuff yet it isn???t a priority for me - I > > > > just want to use it like any other hobbyist. The way things are > > > > now pushes this type of user away from FBSD. > > > > > > > > If there is some philosophical perspective against the diversity > > > > approach then the next best thing is to have documentation that > > > > clearly and simply tells people how to enable the other > > > > functionality. > > > > > > > > Finally, I think there is an opportunity to grow FBSD in the > > > > hobbyist world of these small products. We are past the point > > > > where people can have a real operating system running on systems > > > > at Arduino size and cost. Linux has been aggressively deployed > > > > there but I can say from experience that it ain???t pretty - I > > > > won???t say more as everyone reading this has a clear > > > > understanding of why that is. > > > > > > I'm currently working an issue similar to this, but one that rates > > > "highly annoying" right now rather than "catastrophically bad." > > > > > > The environment is a RPI2 which has GPIO and I2c configured; GPIO > > > to > > > drive outputs, I2c is used to read analog channels. > > > > > > On 11.0 this code ran perfectly well. > > > > > > On 12-STABLE )FreeBSD 12.0-STABLE r344818 GENERIC) > > > it also runs well *BUT* generates a huge number of console > > > messages > > > about spurious interrupts: > > > > > > intc0: Spurious interrupt detected > > > local_intc0: Spurious interrupt detected > > > intc0: Spurious interrupt detected > > > intc0: Spurious interrupt detected > > > local_intc0: Spurious interrupt detected > > > local_intc0: Spurious interrupt detected > > > > > > .... > > > > > > The issue is coming from the i2c side as I have another one of > > > these > > > that has no I2c defined in the configuration (but is running > > > identical > > > code) and no messages. > > > > Interesting. > > A local Pi1 running 12-RELEASE has the same messages: > > intc0: Spurious interrupt detected > > intc0: Spurious interrupt detected > > intc0: Spurious interrupt detected > > intc0: Spurious interrupt detected > > intc0: Spurious interrupt detected > > intc0: Spurious interrupt detected > > intc0: Spurious interrupt detected > > I have an I2C RTC on this machine. > > > > Hmmm, I can't reproduce this. I've got an rpi-b rev2 and I tried 13- > current and the official 12.0-RELEASE image and I have no problems with > interrupts while using an i2c RTC. I also connected an at24c512 eeprom > and did a bunch of reading and writing to it. No spurious interrupts, > and vmstat -i showed a completely reasonable number: > > intc0,61: iichb0 5652 23 > > I don't know what to try next. I see those messages on an RPi B+, an RPi 3 B and RPi 3 B+. All running a GENERIC-NONDEBUG CURRENT up to four weeks old. Those RPi's are directly connected to different monitors via HDMI. There are no (additional?) i2c devices connected. I have got the impression that changing the monitors input to DVI and back triggers the "intc0: Spurious interrupt detected" message here. Some data from today from the RPi 3 B+: $ grep Spuri /var/log/messages Mar 29 09:27:38 IZ-193 kernel: local_intc0: Spurious interrupt detected Mar 29 09:27:38 IZ-193 kernel: intc0: Spurious interrupt detected Mar 29 09:40:36 IZ-193 kernel: intc0: Spurious interrupt detected Mar 29 10:56:29 IZ-193 kernel: intc0: Spurious interrupt detected Mar 29 10:56:29 IZ-193 kernel: local_intc0: Spurious interrupt detected Mar 29 14:50:20 IZ-193 kernel: intc0: Spurious interrupt detected Mar 29 14:50:20 IZ-193 kernel: local_intc0: Spurious interrupt detected Mar 29 14:50:20 IZ-193 kernel: intc0: Spurious interrupt detected $ vmstat -i | grep ichb intc0,61: iichb0 131 0 $ Hmm, changing the monitors input several times while writing this mail causes the message almost every time while this RPi is building a new kernel with make -j4. An remote PRi 2 with 14 days uptime and no monitor input switching did not log any "Spurious interrupt detected" message. It is the same on an RPi 3 B with 24 days uptime and no monitor at all. Ralf From owner-freebsd-arm@freebsd.org Mon Mar 25 15:18:34 2019 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 6C2381564B4C for ; Mon, 25 Mar 2019 15:18:34 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A18470CEA; Mon, 25 Mar 2019 15:18:32 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id x2PFIN8S087415 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Mar 2019 16:18:23 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1553527104; bh=/SCq+eHpPZ9oquSnqjKtp1mZB/mGWbLSybxKHbaFHdQ=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=yXnQy+D8Sz2UAqPq7rTfGOoImfe9kkbcI9l4sTTYW1GIXw7aGT4AGJcEJbyIgL5ma e+WJfK0MwDa3vAmttAu9tVBL/brC5zp2X86Ky/R4bzxj+yJYh11pFwhJmjdUqLM1ES n75ag0eJvU5rTODzkMj3tHMnaaXc10FdE9b2O+oE= Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id x2PFIING030171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Mar 2019 16:18:18 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id x2PFII61090127; Mon, 25 Mar 2019 16:18:18 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id x2PFIH5r090126; Mon, 25 Mar 2019 16:18:17 +0100 (CET) (envelope-from ticso) Date: Mon, 25 Mar 2019 16:18:17 +0100 From: Bernd Walter To: Ian Lepore Cc: ticso@cicely.de, Karl Denninger , freebsd-arm@freebsd.org Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] Message-ID: <20190325151817.GJ57400@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <89f5b8d1ab0614ac8d88b5d5f1afc63e640c3c17.camel@freebsd.org> <4EB5C6C1-7DB9-4DEE-BB23-CD1259581271@jeditekunum.com> <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> <20190319161423.GH57400@cicely7.cicely.de> <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> X-Operating-System: FreeBSD cicely7.cicely.de 12.0-STABLE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-Rspamd-Queue-Id: 0A18470CEA X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cicely.de header.s=default header.b=yXnQy+D8 X-Spamd-Result: default: False [-1.86 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[ticso@cicely.de]; R_DKIM_ALLOW(-0.20)[cicely.de:s=default]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.96)[-0.959,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cicely.de]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[cicely.de:+]; MX_GOOD(-0.01)[mx1.bwct.de]; RCVD_IN_DNSWL_NONE(0.00)[3.99.149.195.list.dnswl.org : 127.0.20.0]; NEURAL_HAM_SHORT(-0.30)[-0.298,0]; NEURAL_HAM_MEDIUM(-0.80)[-0.796,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:21461, ipnet:195.149.99.0/24, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.00)[country: DE(-0.01)] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 15:18:34 -0000 On Sun, Mar 24, 2019 at 05:55:33PM -0600, Ian Lepore wrote: > On Tue, 2019-03-19 at 17:14 +0100, Bernd Walter wrote: > > On Tue, Mar 19, 2019 at 09:55:12AM -0500, Karl Denninger wrote: > > > On 3/19/2019 09:26, Jedi Tek'Unum wrote: > > > > On Mar 18, 2019, at 2:57 PM, Ian Lepore wrote: > > > > > On Mon, 2019-03-18 at 14:51 -0500, Jedi Tek'Unum wrote: > > > > > > My impression wasn???t that support wasn???t there - but > > > > > > ???out of the box??? > > > > > > configuration wasn???t there. In comparison, I didn???t have > > > > > > to do > > > > > > anything to get I2C enabled in the binary distribution of > > > > > > Linux that > > > > > > comes through the manufacturer. > > > > > > > > > > > > Its the enabling part that isn???t obvious to most people > > > > > > IMO. > > > > > > > > > > > > Documentation/wiki is great. But even better would be all the > > > > > > enabling overlays already in place and the entries in > > > > > > loader.conf > > > > > > already there and commented out. It would be so much easier > > > > > > to go to > > > > > > a ???common place??? (loader.conf), skim through the notes, > > > > > > find the > > > > > > thing that one wants, and then just uncomment the referenced > > > > > > line! > > > > > > (Or any other similarly easy method.) > > > > > > > > > > > > > > > > > > For FBSD to get a better foothold in this space it needs to > > > > > > be better > > > > > > documented. For example, the wiki for NEO2 < > > > > > > http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2>; is a > > > > > > step-by- > > > > > > step guide for how to acquire and configure Linux for it. > > > > > > > > > > > > > > > > > > > > > > On one of my imx6 boards I have 5 SPI devices. Each device can > > > > > use 3 > > > > > or 4 different sets of pins for clock, data-in, and data- > > > > > out. Plus, > > > > > each can use literally any number of whatever gpio pins they > > > > > want as > > > > > chip selects. Even limiting the chipsels to a handfull, there > > > > > would > > > > > literally be thousands of possible combinations of devices and > > > > > pin > > > > > configurations, each one needing to be a separate overlay. > > > > > > > > > > Maybe you have experience primarily with rpi or some similarly > > > > > crippled > > > > > devices that only offer one or two choices? > > > > > > > > If memory serves correctly, there are only 2 I2C devices on the > > > > H3/H5 and the NanoPi NEO/2 implementations only externalize 1. > > > > There is only 1 SPI AFAIK. > > > > > > > > I wouldn???t call that crippled. I chose this platform exactly > > > > because of its characteristics - small, fast, cheap. It fits the > > > > project I???m using it for perfectly. In fact, I can see uses for > > > > even smaller (see Giant Board > > > >). I understand other projects may have different requirements > > > > and would drive one towards different solutions - and require > > > > more of the various interfaces. But they aren???t going to be > > > > typical of hobbyist projects. > > > > > > > > Maybe I should pose the question in another way. What is the > > > > philosophy for choosing GPIO as default for all the pins? These > > > > boards have a very limited number of pins and my preference would > > > > be that the broadest range of interface types would be the > > > > default. There are 2 UARTs exposed so I would have picked 1 to be > > > > enabled by default. After that, with I2C and SPI enabled, there > > > > are still 6 GPIO available. For a tiny board like this that seems > > > > to be reasonable. If people have a need for slightly more GPIO > > > > then I would expect they would be the ones configuring overlays. > > > > > > > > Apparently the developers of the Linux packages for these boards > > > > have chosen the diverse approach (???FriendlyCore??? based on > > > > UbuntuCore Xenial). > > > > > > > > IMHO, most ???hobbyists??? would prefer the diversity approach. > > > > I???m completely capable of becoming an expert in FBSD and this > > > > sort of configuration stuff yet it isn???t a priority for me - I > > > > just want to use it like any other hobbyist. The way things are > > > > now pushes this type of user away from FBSD. > > > > > > > > If there is some philosophical perspective against the diversity > > > > approach then the next best thing is to have documentation that > > > > clearly and simply tells people how to enable the other > > > > functionality. > > > > > > > > Finally, I think there is an opportunity to grow FBSD in the > > > > hobbyist world of these small products. We are past the point > > > > where people can have a real operating system running on systems > > > > at Arduino size and cost. Linux has been aggressively deployed > > > > there but I can say from experience that it ain???t pretty - I > > > > won???t say more as everyone reading this has a clear > > > > understanding of why that is. > > > > > > I'm currently working an issue similar to this, but one that rates > > > "highly annoying" right now rather than "catastrophically bad." > > > > > > The environment is a RPI2 which has GPIO and I2c configured; GPIO > > > to > > > drive outputs, I2c is used to read analog channels. > > > > > > On 11.0 this code ran perfectly well. > > > > > > On 12-STABLE )FreeBSD 12.0-STABLE r344818 GENERIC) > > > it also runs well *BUT* generates a huge number of console > > > messages > > > about spurious interrupts: > > > > > > intc0: Spurious interrupt detected > > > local_intc0: Spurious interrupt detected > > > intc0: Spurious interrupt detected > > > intc0: Spurious interrupt detected > > > local_intc0: Spurious interrupt detected > > > local_intc0: Spurious interrupt detected > > > > > > .... > > > > > > The issue is coming from the i2c side as I have another one of > > > these > > > that has no I2c defined in the configuration (but is running > > > identical > > > code) and no messages. > > > > Interesting. > > A local Pi1 running 12-RELEASE has the same messages: > > intc0: Spurious interrupt detected > > intc0: Spurious interrupt detected > > intc0: Spurious interrupt detected > > intc0: Spurious interrupt detected > > intc0: Spurious interrupt detected > > intc0: Spurious interrupt detected > > intc0: Spurious interrupt detected > > I have an I2C RTC on this machine. > > > > Hmmm, I can't reproduce this. I've got an rpi-b rev2 and I tried 13- > current and the official 12.0-RELEASE image and I have no problems with > interrupts while using an i2c RTC. I also connected an at24c512 eeprom > and did a bunch of reading and writing to it. No spurious interrupts, > and vmstat -i showed a completely reasonable number: > > intc0,61: iichb0 5652 23 > > I don't know what to try next. This is on my system: [9]time1# vmstat -i interrupt total rate intc0,2: vchiq0 2 0 intc0,11: systimer0 2811547017 1119 intc0,17: + 288731204 115 intc0,28: bcm_dma0 25127004 10 intc0,61: iichb0 8384 0 intc0,65: uart0 249 0 intc0,70: + 4650145 2 Total 3130064005 1246 nxprtc0: at addr 0xa2 on iicbus0 It seems it doesn't happen very often: [19]time1# bzgrep Spuri /var/log/all.log.*.bz2 /var/log/all.log.0.bz2:Mar 24 03:12:04 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.0.bz2:Mar 24 07:12:04 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.0.bz2:Mar 24 14:42:04 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.0.bz2:Mar 24 15:42:04 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.0.bz2:Mar 24 17:42:04 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.1.bz2:Mar 23 02:12:04 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.1.bz2:Mar 23 09:12:04 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.2.bz2:Mar 22 02:12:03 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.2.bz2:Mar 22 17:12:04 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.2.bz2:Mar 22 18:12:04 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.2.bz2:Mar 22 22:42:04 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.3.bz2:Mar 21 01:12:03 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.3.bz2:Mar 21 02:42:03 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.3.bz2:Mar 21 10:12:03 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.3.bz2:Mar 21 13:42:03 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.3.bz2:Mar 21 14:12:03 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.3.bz2:Mar 21 19:42:03 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.4.bz2:Mar 20 08:42:03 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.4.bz2:Mar 20 19:42:03 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.5.bz2:Mar 19 04:42:03 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.5.bz2:Mar 19 10:12:03 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.5.bz2:Mar 19 11:12:03 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.5.bz2:Mar 19 13:42:03 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.6.bz2:Mar 18 05:12:02 time1 kernel: intc0: Spurious interrupt detected /var/log/all.log.6.bz2:Mar 18 13:12:03 time1 kernel: intc0: Spurious interrupt detected [20]time1# grep Spuri /var/log/all.log Mar 25 03:42:04 time1 kernel: intc0: Spurious interrupt detected Maybe the iic is a red hering. It is just that we both use it. But they all are within a 30min grid and it is aligned to boottime. I don't see the local_intc0 messages on my system. Mine is a stock FreeBSD-12, just rearranged the image data for zroot and modules/dtbo loaded for zroot and rtc. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Mon Mar 25 15:19:58 2019 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 7AF771564BF2 for ; Mon, 25 Mar 2019 15:19:58 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CEC8970DAC; Mon, 25 Mar 2019 15:19:57 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id x2PFJr1M087450 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Mar 2019 16:19:54 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1553527195; bh=er6ZVGza4pMh372gzW5hj+8i75aUAi6662YqaO2Z+Ss=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=YC/MbhPAVxRx7AmWjz+Kdf4ubQQqhnsONEIake1oL+VrqMM2g1rExD0v7c5P0dS79 7926T6+jxJSZnJrdmwoQAv9UuPLn1qlH8JJV4KvuAGLr6PfIlCIvpcolic+SNzqpJ6 y28Qc0zf9zt/OCe+DH+31qgZa3OJJcPbCi2ncWkI= Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id x2PFJnFO030192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Mar 2019 16:19:49 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id x2PFJnHb090151; Mon, 25 Mar 2019 16:19:49 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id x2PFJnN9090150; Mon, 25 Mar 2019 16:19:49 +0100 (CET) (envelope-from ticso) Date: Mon, 25 Mar 2019 16:19:49 +0100 From: Bernd Walter To: Ian Lepore Cc: Karl Denninger , freebsd-arm@freebsd.org Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] Message-ID: <20190325151949.GK57400@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <0ecf23e129ca7ac6a92a01bbb34c03f1ac8c6dc8.camel@freebsd.org> <89f5b8d1ab0614ac8d88b5d5f1afc63e640c3c17.camel@freebsd.org> <4EB5C6C1-7DB9-4DEE-BB23-CD1259581271@jeditekunum.com> <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 12.0-STABLE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-Rspamd-Queue-Id: CEC8970DAC X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cicely.de header.s=default header.b=YC/MbhPA X-Spamd-Result: default: False [-1.88 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[ticso@cicely.de]; R_DKIM_ALLOW(-0.20)[cicely.de:s=default]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.96)[-0.958,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cicely.de]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[cicely.de:+]; MX_GOOD(-0.01)[cached: mx1.bwct.de]; RCVD_IN_DNSWL_NONE(0.00)[3.99.149.195.list.dnswl.org : 127.0.20.0]; NEURAL_HAM_SHORT(-0.32)[-0.317,0]; NEURAL_HAM_MEDIUM(-0.80)[-0.795,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:21461, ipnet:195.149.99.0/24, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.00)[country: DE(-0.01)] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 15:19:58 -0000 On Wed, Mar 20, 2019 at 09:00:17AM -0600, Ian Lepore wrote: > On Tue, 2019-03-19 at 09:55 -0500, Karl Denninger wrote: > > On 3/19/2019 09:26, Jedi Tek'Unum wrote: > > > On Mar 18, 2019, at 2:57 PM, Ian Lepore wrote: > > > > On Mon, 2019-03-18 at 14:51 -0500, Jedi Tek'Unum wrote: > > > > > My impression wasn???t that support wasn???t there - but ???out of > > > > > the box??? > > > > > configuration wasn???t there. In comparison, I didn???t have to do > > > > > anything to get I2C enabled in the binary distribution of Linux > > > > > that > > > > > comes through the manufacturer. > > > > > > > > > > Its the enabling part that isn???t obvious to most people IMO. > > > > > > > > > > Documentation/wiki is great. But even better would be all the > > > > > enabling overlays already in place and the entries in > > > > > loader.conf > > > > > already there and commented out. It would be so much easier to > > > > > go to > > > > > a ???common place??? (loader.conf), skim through the notes, find > > > > > the > > > > > thing that one wants, and then just uncomment the referenced > > > > > line! > > > > > (Or any other similarly easy method.) > > > > > > > > > > > > > > > For FBSD to get a better foothold in this space it needs to be > > > > > better > > > > > documented. For example, the wiki for NEO2 < > > > > > http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2>; is a > > > > > step-by- > > > > > step guide for how to acquire and configure Linux for it. > > > > > > > > > > > > > > > > > > On one of my imx6 boards I have 5 SPI devices. Each device can > > > > use 3 > > > > or 4 different sets of pins for clock, data-in, and data- > > > > out. Plus, > > > > each can use literally any number of whatever gpio pins they want > > > > as > > > > chip selects. Even limiting the chipsels to a handfull, there > > > > would > > > > literally be thousands of possible combinations of devices and > > > > pin > > > > configurations, each one needing to be a separate overlay. > > > > > > > > Maybe you have experience primarily with rpi or some similarly > > > > crippled > > > > devices that only offer one or two choices? > > > > > > If memory serves correctly, there are only 2 I2C devices on the > > > H3/H5 and the NanoPi NEO/2 implementations only externalize 1. > > > There is only 1 SPI AFAIK. > > > > > > I wouldn???t call that crippled. I chose this platform exactly > > > because of its characteristics - small, fast, cheap. It fits the > > > project I???m using it for perfectly. In fact, I can see uses for > > > even smaller (see Giant Board ) > > > . I understand other projects may have different requirements and > > > would drive one towards different solutions - and require more of > > > the various interfaces. But they aren???t going to be typical of > > > hobbyist projects. > > > > > > Maybe I should pose the question in another way. What is the > > > philosophy for choosing GPIO as default for all the pins? These > > > boards have a very limited number of pins and my preference would > > > be that the broadest range of interface types would be the default. > > > There are 2 UARTs exposed so I would have picked 1 to be enabled by > > > default. After that, with I2C and SPI enabled, there are still 6 > > > GPIO available. For a tiny board like this that seems to be > > > reasonable. If people have a need for slightly more GPIO then I > > > would expect they would be the ones configuring overlays. > > > > > > Apparently the developers of the Linux packages for these boards > > > have chosen the diverse approach (???FriendlyCore??? based on > > > UbuntuCore Xenial). > > > > > > IMHO, most ???hobbyists??? would prefer the diversity approach. I???m > > > completely capable of becoming an expert in FBSD and this sort of > > > configuration stuff yet it isn???t a priority for me - I just want to > > > use it like any other hobbyist. The way things are now pushes this > > > type of user away from FBSD. > > > > > > If there is some philosophical perspective against the diversity > > > approach then the next best thing is to have documentation that > > > clearly and simply tells people how to enable the other > > > functionality. > > > > > > Finally, I think there is an opportunity to grow FBSD in the > > > hobbyist world of these small products. We are past the point where > > > people can have a real operating system running on systems at > > > Arduino size and cost. Linux has been aggressively deployed there > > > but I can say from experience that it ain???t pretty - I won???t say > > > more as everyone reading this has a clear understanding of why that > > > is. > > > > I'm currently working an issue similar to this, but one that rates > > "highly annoying" right now rather than "catastrophically bad." > > > > The environment is a RPI2 which has GPIO and I2c configured; GPIO to > > drive outputs, I2c is used to read analog channels. > > > > On 11.0 this code ran perfectly well. > > > > On 12-STABLE )FreeBSD 12.0-STABLE r344818 GENERIC) > > it also runs well *BUT* generates a huge number of console messages > > about spurious interrupts: > > > > intc0: Spurious interrupt detected > > local_intc0: Spurious interrupt detected > > intc0: Spurious interrupt detected > > intc0: Spurious interrupt detected > > local_intc0: Spurious interrupt detected > > local_intc0: Spurious interrupt detected > > > > .... > > > > The issue is coming from the i2c side as I have another one of these > > that has no I2c defined in the configuration (but is running > > identical > > code) and no messages. > > > > Something is indeed generating an /insane /number of interrupts on > > one > > of the channels: > > > > Interrupts > > 530k total > > 1159 local_intc > > 494k local_intc > > 8047 local_intc > > > > For obvious reasons I'd like to track this down (it's also generating > > a > > load average of 1.0, where it should be 0.1 or thereabouts) but I'm > > not > > sure where to start looking. > > > > config.txt looks like this: > > > > root@Pool-MCP:/mnt # cat config.txt > > init_uart_clock=3000000 > > enable_uart=1 > > kernel=u-boot.bin > > kernel7=u-boot.bin > > dtoverlay=mmc > > #audio_pwm_mode=2 > > dtparam=i2c_arm=on > > > > The only "change" from what is in the default is the i2c_arm=on line. > > > > The "something" appears to be the i2c code, *or* it's something > > that's > > gone wrong in the DTS changes that are in the newer way of building > > the > > boot area (where the grab is of the "standard" versions from ports > > and > > then just copied over.) > > > > I suspect this would bite you equally hard if you had a RTC > > configured > > on I2c as well..... > > > > Killing the process that has the I2c interface open (so the I2c > > interface is not in active use, but is configured of course) does > > *not* > > stop the insane interrupt storm. > > > > I'm aware of this (haven't forgotten that you reported it), but I > haven't had time to look into it, because of a crazy $work schedule > right now. I did some work on the rpi i2c driver last year, so there's > a chance I caused this problem. I only have an ancient rpi-b to test > with, I wonder if this is a problem that only happens on rpi2 models? My system is a Pi1 - one of the later models with 512MB RAM and 4-port USB. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Mon Mar 25 16:34:05 2019 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 892C21545139 for ; Mon, 25 Mar 2019 16:34:05 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 B3633746D1; Mon, 25 Mar 2019 16:34:04 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 6AC11211098; Mon, 25 Mar 2019 12:33:33 -0400 (EDT) Received: from [192.168.10.14] (D4.Denninger.Net [192.168.10.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id AE981D0B4B; Mon, 25 Mar 2019 11:33:32 -0500 (CDT) Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] To: Ian Lepore References: <8df902f6-20a3-31c4-71ac-91f5d5fdf50d@optiplex-networks.com> <0ecf23e129ca7ac6a92a01bbb34c03f1ac8c6dc8.camel@freebsd.org> <89f5b8d1ab0614ac8d88b5d5f1afc63e640c3c17.camel@freebsd.org> <4EB5C6C1-7DB9-4DEE-BB23-CD1259581271@jeditekunum.com> <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> <20190319161423.GH57400@cicely7.cicely.de> <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> <40f57de2-2b25-3981-a416-b9958cc97636@denninger.net> <669892ac3fc37b0843a156c0ab102316829103fd.camel@freebsd.org> Cc: "freebsd-arm@freebsd.org" From: Karl Denninger Openpgp: preference=signencrypt Autocrypt: addr=karl@denninger.net; prefer-encrypt=mutual; keydata= mQINBFIX1zsBEADRcJfsQUl9oFeoMfLPJ1kql+3sIaYx0MfJAUhV9LnbWxr0fsWCskM1O4cV tHm5dqPkuPM4Ztc0jLotD1i9ubWvCHOlkLGxFOL+pFbjA+XZ7VKsC/xWmhMwJ3cM8HavK2OV SzEWQ/AEYtMi04IzGSwsxh/5/5R0mPHrsIomV5SbuiI0vjLuDj7fo6146AABI1ULzge4hBYW i/SHrqUrLORmUNBs6bxek79/B0Dzk5cIktD3LOfbT9EAa5J/osVkstMBhToJgQttaMIGv8SG CzpR/HwEokE+7DP+k2mLHnLj6H3kfugOF9pJH8Za4yFmw//s9cPXV8WwtZ2SKfVzn1unpKqf wmJ1PwJoom/d4fGvQDkgkGKRa6RGC6tPmXnqnx+YX4iCOdFfbP8L9rmk2sewDDVzHDU3I3ZZ 8hFIjMYM/QXXYszRatK0LCV0QPZuF7LCf4uQVKw1/oyJInsnH7+6a3c0h21x+CmSja9QJ+y0 yzgEN/nM89d6YTakfR+1xkYgodVmMy/bS8kmXbUUZG/CyeqCqc95RUySjKT2ECrf9GhhoQkl +D8n2MsrAUSMGB4GQSN+TIq9OBTpNuvATGSRuF9wnQcs1iSry+JNCpfRTyWp83uCNApe6oHU EET4Et6KDO3AvjvBMAX0TInTRGW2SQlJMuFKpc7Dg7tHK8zzqQARAQABtCNLYXJsIERlbm5p bmdlciA8a2FybEBkZW5uaW5nZXIubmV0PokCPAQTAQIAJgUCUhfXOwIbIwUJCWYBgAYLCQgH AwIEFQIIAwQWAgMBAh4BAheAAAoJEG6/sivc5s0PLxQP/i6x/QFx9G4Cw7C+LthhLXIm7NSH AtNbz2UjySEx2qkoQQjtsK6mcpEEaky4ky6t8gz0/SifIfJmSmyAx0UhUQ0WBv1vAXwtNrQQ jJd9Bj6l4c2083WaXyHPjt2u2Na6YFowyb4SaQb83hu/Zs25vkPQYJVVE0JX409MFVPUa6E3 zFbd1OTr3T4yNUy4gNeQZfzDqDS8slbIks2sXeoJrZ6qqXVI0ionoivOlaN4T6Q0UYyXtigj dQvvhMt0aNowKFjRqrmSDRpdz+o6yg7Mp7qEZ1V6EZk8KqQTH6htpCTQ8i79ttK4LG6bstSF Re6Fwq52nbrcANrcdmtZXqjo+SGbUqJ8b1ggrxAsJ5MEhRh2peKrCgI/TjQo+ZxfnqEoR4AI 46Cyiz+/lcVvlvmf2iPifS3EEdaH3Itfwt7MxFm6mQORYs6skHDw3tOYB2/AdCW6eRVYs2hB RMAG4uwApZfZDKgRoE95PJmQjeTBiGmRPcsQZtNESe7I7EjHtCDLwtJqvD4HkDDQwpzreT6W XkyIJ7ns7zDfA1E+AQhFR6rsTFGgQZRZKsVeov3SbhYKkCnVDCvb/PKQCAGkSZM9SvYG5Yax 8CMry3AefKktf9fqBFg8pWqtVxDwJr56dhi0GHXRu3jVI995rMGo1fLUG5fSxiZ8L5sAtokh 9WFmQpyl Message-ID: <663f2566-b035-7011-70eb-4163b41e6e55@denninger.net> Date: Mon, 25 Mar 2019 11:33:32 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <669892ac3fc37b0843a156c0ab102316829103fd.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050906090601090507070504" X-Rspamd-Queue-Id: B3633746D1 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.03 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: px.denninger.net]; RCPT_COUNT_TWO(0.00)[2]; MIME_BASE64_TEXT(0.10)[]; NEURAL_HAM_SHORT(-0.63)[-0.627,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:+]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[197.57.1.68.zen.spamhaus.org : 127.0.0.11]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; DMARC_NA(0.00)[denninger.net]; AUTH_NA(1.00)[]; IP_SCORE(-2.30)[ip: (-9.88), ipnet: 104.236.64.0/18(-3.57), asn: 14061(2.02), country: US(-0.07)]; R_SPF_NA(0.00)[] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 16:34:06 -0000 This is a cryptographically signed message in MIME format. --------------ms050906090601090507070504 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 DQo+IFdoYXQgZG8geW91IG1lYW4gYnkgYW4gaW5zYW5lIHJhdGU/ICBJdCdzIG5vcm1hbCBm b3IgdGhlIHVzYiBjb250cm9sbGVyDQo+IHRvIGJlIHNob3dpbmcgYXJvdW5kIHRob3VzYW5k cyBvZiBpbnQvc2VjLiAgRGVzcGl0ZSB3aGF0IHNlZW1zIGxpa2UgYQ0KPiBoaWdoIHJhdGUs IGV2ZW4gb24gYW4gb24gcnBpLWIgaXQgdXNlcyB1bmRlciAyJSBjcHUgdG8gc2VydmljZSB0 aGF0Lg0KPg0KPiByb290QHJwaTp+ICMgdm1zdGF0IC1pDQo+IGludGVycnVwdCAgICAgICAg ICAgICAgICAgICAgICAgIHRvdGFsICAgICAgIHJhdGUNCj4gaW50YzAsMjogdmNoaXEwICAg ICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgMA0KPiBpbnRjMCwxMTogc3lzdGltZXIw ICAgICAgICAgICAxMDEwMzIwNiAgICAgICAxMTEwDQo+IGludGMwLDE3Oi14X2R3Y290ZzAg ICAgICAgICAgMjE4NTk2MDU1ICAgICAgMjQwMDcNCj4gaW50YzAsMjg6IGJjbV9kbWEwICAg ICAgICAgICAgICAgICA4MzQgICAgICAgICAgMA0KPiBpbnRjMCw2MTogaWljaGIwICAgICAg ICAgICAgICAgICAgNTc3OCAgICAgICAgICAxDQo+IGludGMwLDY1OiB1YXJ0MCAgICAgICAg ICAgICAgICAgICAxODE3ICAgICAgICAgIDANCj4gaW50YzAsNzA6LWRoY2lfYmNtMCAgICAg ICAgICAgICAgICAxNzIgICAgICAgICAgMA0KPiBUb3RhbCAgICAgICAgICAgICAgICAgICAg ICAgIDIyODcwNzg2NCAgICAgIDI1MTE4DQo+DQo+IC0tIElhbg0KDQpUaGUgc3RvcnkgZ2V0 cyBtb3JlIG9kZC4NCg0KVGhlIHNhbWUgKnBoeXNpY2FsKiB1bml0IHRoYXQgSSBzYXcgdGhp cyBvbiBsYXN0IG5pZ2h0IHdpdGggbm8gSTJjDQpkZXZpY2UgY29ubmVjdGVkIEkgcmVzdGFy dGVkIHRoaXMgbW9ybmluZyAtLSBjaGFuZ2luZyBOT1RISU5HIC0tIGFuZCBpdA0KZGlzYXBw ZWFyZWQuDQoNCkJ1dCAtLSBvbiBhbm90aGVyIHVuaXQgaXQncyBzdGlsbCB0aGVyZSAoSSBo YXZlbid0IHNodXQgZG93biwgcHVsbGVkDQpwb3dlciBhbmQgcmVzdGFydGVkIHRoYXQgb25l LikNCg0Kdm1zdGF0IC1pIG9uIGJvdGggZG9lc24ndCBzaG93IGFueXRoaW5nIGFsbCB0aGF0 IG9kZDoNCg0Kcm9vdEBQb29sLU1DUDp+ICMgdm1zdGF0IC1pDQppbnRlcnJ1cHTCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHRvdGFswqDCoMKgwqDCoMKgIHJhdGUNCmxv Y2FsX2ludGMwLDE6ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDYwMDc4MTLCoMKgwqDCoMKgwqAgMTE0 Mw0KbG9jYWxfaW50YzAsODogK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDgyODM0MDgywqDCoMKgwqDCoCAx NTc1NA0KbG9jYWxfaW50YzAsOTogcG11MMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDg2wqDCoMKg wqDCoMKgwqDCoMKgIDANCmludGMwLDE6IG1ib3gwwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCAyNjjCoMKgwqDCoMKgwqDCoMKgwqAgMA0KaW50YzAsMjogdmNoaXEwwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIDLCoMKgwqDCoMKgwqDCoMKgwqAgMA0KaW50YzAsMTc6 ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDEyNjY5Mzg4M8KgwqDCoMKgwqAgMjQwOTYNCmlu dGMwLDI4OiBiY21fZG1hMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgODk2OTbCoMKgwqDCoMKgwqDCoMKg IDE3DQppbnRjMCw2MTogaWljaGIwwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAxwqDC oMKgwqDCoMKgwqDCoMKgIDANCmludGMwLDY1OiB1YXJ0MMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCA0MzYywqDCoMKgwqDCoMKgwqDCoMKgIDENCmludGMwLDcwOiArwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDE1NjIwwqDCoMKgwqDCoMKgwqDCoMKgIDMNCmNwdTA6cmVu ZGV6dm91c8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgNDfCoMKgwqDCoMKgwqDCoMKg wqAgMA0KY3B1MTpyZW5kZXp2b3VzwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAyOMKg wqDCoMKgwqDCoMKgwqDCoCAwDQpjcHUyOnJlbmRlenZvdXPCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIDQ4wqDCoMKgwqDCoMKgwqDCoMKgIDANCmNwdTM6cmVuZGV6dm91c8KgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgNTPCoMKgwqDCoMKgwqDCoMKgwqAgMA0KY3B1MDpw cmVlbXB0wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAzNDQ0N8KgwqDCoMKgwqDCoMKg wqDCoCA3DQpjcHUxOnByZWVtcHTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAxNzc0ODjC oMKgwqDCoMKgwqDCoMKgIDM0DQpjcHUyOnByZWVtcHTCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCAxNjQ0NzTCoMKgwqDCoMKgwqDCoMKgIDMxDQpjcHUzOnByZWVtcHTCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCAxNzI5NzDCoMKgwqDCoMKgwqDCoMKgIDMzDQpjcHUwOmhhcmRj bG9ja8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDPCoMKgwqDCoMKgwqDCoMKg wqAgMA0KVG90YWzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDIxNjE5NTM3 MMKgwqDCoMKgwqAgNDExMTkNCg0KVGhpcyBpcyB0aGUgaW5zdGFuY2UgdGhhdCBpcyAqbm90 KiBkb2luZyBpdC4NCg0KVGhlIG9uZSB0aGF0IGlzOg0KDQpyb290QFBvb2wtTUNQOi9kYXRh L2thcmwgIyB2bXN0YXQgLWkNCmludGVycnVwdMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgdG90YWzCoMKgwqDCoMKgwqAgcmF0ZQ0KbG9jYWxfaW50YzAsMTogK8KgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCAxMTcyMTMxOTDCoMKgwqDCoMKgwqAgMTE2MA0KbG9jYWxfaW50YzAsMzogK8Kg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgMjc3NTU5MDk2NsKgwqDCoMKgwqAgMjc0NjMNCmxvY2FsX2ludGMwLDg6ICvC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgODE4MzQ2MTU5wqDCoMKgwqDCoMKgIDgwOTcNCmxvY2FsX2ludGMwLDk6 IHBtdTDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIDE4ODjCoMKgwqDCoMKgwqDCoMKgwqAgMA0KaW50YzAs MTogbWJveDDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAxODc2wqDCoMKgwqDCoMKgwqDC oMKgIDANCmludGMwLDI6IHZjaGlxMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAy wqDCoMKgwqDCoMKgwqDCoMKgIDANCmludGMwLDE3OiArwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg MjY1ODY4NTE4NcKgwqDCoMKgwqAgMjYzMDYNCmludGMwLDI4OiBiY21fZG1hMMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIDE0MTg4McKgwqDCoMKgwqDCoMKgwqDCoCAxDQppbnRjMCw2MTogaWljaGIwwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIDQzMjYxOMKgwqDCoMKgwqDCoMKgwqDCoCA0DQppbnRjMCw2NTog dWFydDDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA0MTXCoMKgwqDCoMKgwqDCoMKgwqAg MA0KaW50YzAsNzA6ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMjA1NTbCoMKg wqDCoMKgwqDCoMKgwqAgMA0KY3B1MDpyZW5kZXp2b3VzwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCA4MMKgwqDCoMKgwqDCoMKgwqDCoCAwDQpjcHUxOnJlbmRlenZvdXPCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIDk0wqDCoMKgwqDCoMKgwqDCoMKgIDANCmNwdTI6cmVu ZGV6dm91c8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgNjLCoMKgwqDCoMKgwqDCoMKg wqAgMA0KY3B1MzpyZW5kZXp2b3VzwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA2MsKg wqDCoMKgwqDCoMKgwqDCoCAwDQpjcHUwOmFzdMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDHCoMKgwqDCoMKgwqDCoMKgwqAgMA0KY3B1Mjphc3TCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA0wqDCoMKgwqDCoMKg wqDCoMKgIDANCmNwdTM6YXN0wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgMsKgwqDCoMKgwqDCoMKgwqDCoCAwDQpjcHUwOnByZWVtcHTCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgMTYxODM1OcKgwqDCoMKgwqDCoMKgwqAgMTYNCmNwdTI6cHJlZW1w dMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA5Nzk3ODQ5wqDCoMKgwqDCoMKgwqDCoCA5Nw0K Y3B1MzpwcmVlbXB0wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDk4NTMwNzLCoMKgwqDCoMKg wqDCoMKgIDk3DQpjcHUwOmhhcmRjbG9ja8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIDbCoMKgwqDCoMKgwqDCoMKgwqAgMA0KVG90YWzCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCA2MzkxNzA0MzI3wqDCoMKgwqDCoCA2MzI0Mw0KDQpCb3RoIHJ1bm5pbmcg aWRlbnRpY2FsIGNvcGllcyBvZiB0aGUgY29kZSAoc2FtZSBidWlsZCwgc2FtZSBldmVyeXRo aW5nLikNCg0KTm93LCBoZXJlJ3MgdGhlIHRoaW5nIC0tIG9uIHRoZSBvbmUgdGhhdCdzIGRv aW5nIGl0IHRoZSBsb2FkIGF2ZXJhZ2UgaXMNCjEuMDQgLS0gb25seSAuMDQgaXMgcmVhbCBh cyB0aGUgY29kZSBydW5uaW5nIG9uIHRoYXQgYm94IGlzIGV4dHJlbWVseQ0KZWZmaWNpZW50 IChpdCByZWFkcyBhbmFsb2cgSTJjIGlucHV0cyBhbmQgYWN0cyBvbiB0aGVtIGJ5IGZsaXBw aW5nDQpHUElPcywgcGx1cyByZXBvcnRpbmcgc3RhdHVzLinCoCBUaGUgcmVzdCBpcyB0aGUg aW50ZXJydXB0cyBidXQgdm1zdGF0IC1pDQpkb2Vzbid0IHNob3cgaXQuwqAgInN5c3RhdCAt dm0iLCBob3dldmVyLCBET0VTOg0KDQrCoMKgwqAgMSB1c2Vyc8KgwqDCoCBMb2FkwqAgMS4w McKgIDEuMDLCoCAxLjAwwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBNYXIg MjUgMTE6MjQNCsKgwqAgTWVtIHVzYWdlOsKgIDE0JVBoeSAxNCVLbWVtDQpNZW06IEtCwqDC oMKgIFJFQUzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFZJUlRVQUzCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgVk4gUEFHRVLCoMKgIFNXQVANClBBR0VSDQrC oMKgwqDCoMKgwqDCoCBUb3TCoMKgIFNoYXJlwqDCoMKgwqDCoCBUb3TCoMKgwqAgU2hhcmXC oMKgwqAgRnJlZcKgwqDCoMKgwqDCoMKgwqDCoMKgIGluwqDCoCBvdXTCoMKgwqDCoA0KaW7C oMKgIG91dA0KQWN0wqDCoCAyOTY1NsKgwqDCoCA5MTMywqDCoCAxMzgyODjCoMKgwqAgMTAw OTLCoCA4MDQzNDTCoCBjb3VudA0KQWxswqDCoCAzMDMwOMKgwqDCoCA5NzY4wqDCoCAxNDAw MjDCoMKgwqAgMTE4MDjCoMKgwqDCoMKgwqDCoMKgwqAgcGFnZXMNClByb2M6wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCBJbnRlcnJ1cHRzDQrCoCBywqDCoCBwwqDCoCBkwqDCoCBzwqDCoCB3wqDCoCBDc3fCoCBU cnDCoCBTeXPCoCBJbnTCoCBTb2bCoCBGbHTCoMKgwqDCoMKgwqDCoCBpb2ZsdMKgIDUzMGsg dG90YWwNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAyN8KgwqDCoMKgwqDCoCA5NDjCoMKg IDQ0wqAgMjc5IDk0NjLCoCAxMDPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY293wqDCoMKg IDExNjYNCmxvY2FsX2ludGMNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB6Zm9kwqDCoCA0OTVrDQpsb2NhbF9pbnRjDQrC oDAuMiVTeXPCoMKgIDAuMCVJbnRywqAgMC4yJVVzZXLCoCAwLjAlTmljZSA5OS42JUlkbGXC oMKgwqDCoMKgwqDCoMKgIG96Zm9kwqAgODA5OQ0KbG9jYWxfaW50Yw0KfMKgwqDCoCB8wqDC oMKgIHzCoMKgwqAgfMKgwqDCoCB8wqDCoMKgIHzCoMKgwqAgfMKgwqDCoCB8wqDCoMKgIHzC oMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgICVvemZvZMKgwqDCoMKgwqDCoA0KbG9jYWxf aW50Yw0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIGRhZWZywqDCoMKgwqDCoMKgDQppbnRjMCwxOiBtDQrCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgZHRidWbCoMKgwqDCoMKgwqDCoMKgwqAgcHJjZnLCoMKg wqDCoMKgwqANCmludGMwLDI6IHYNCk5hbWVpwqDCoMKgwqAgTmFtZS1jYWNoZcKgwqAgRGly LWNhY2hlwqDCoMKgwqAgMzA4MDUgZGVzdm7CoMKgwqDCoMKgwqDCoMKgwqAgdG90ZnIgMjYy MDUNCmludGMwLDE3Og0KwqDCoCBDYWxsc8KgwqDCoCBoaXRzwqDCoCAlwqDCoMKgIGhpdHPC oMKgICXCoMKgwqDCoCAzMDgwNSBudW12bsKgwqDCoMKgwqDCoMKgwqDCoCByZWFjdMKgwqDC oMKgwqDCoA0KaW50YzAsMjg6DQrCoMKgwqAgMjU1NsKgwqDCoCAyNTU2IDEwMMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDI4Mzk5IGZyZXZuwqDCoMKgwqDCoMKgwqDCoMKg IHBkd2FrwqDCoMKgwqAgNA0KaW50YzAsNjE6DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAyIHBkcGdzwqDCoMKgwqDCoMKgDQpp bnRjMCw2NToNCkRpc2tzIG1tY3NkwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgaW50cm7CoMKgwqDCoMKgwqANCmludGMwLDcwOg0KS0IvdMKgwqAgMC4wMMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCAxMDk3MTYgd2lyZcKgwqDCoMKgwqDCoMKgDQpjcHUwOnJl bmRlDQp0cHPCoMKgwqDCoMKgwqAgMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgNjI1 NiBhY3TCoMKgwqDCoMKgwqDCoMKgDQpjcHUxOnJlbmRlDQpNQi9zwqDCoCAwLjAwwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgMTgxNzIgaW5hY3TCoMKgwqDCoMKgwqANCmNwdTI6cmVu ZGUNCiVidXN5wqDCoMKgwqAgMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIGxhdW5kwqDCoMKgwqDCoMKgDQpjcHUzOnJlbmRlDQrCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDgwNDM0NCBmcmVlwqDCoMKgwqDCoMKgwqAN CmNwdTA6YXN0DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgNTUxNjggYnVmwqDCoMKgwqDCoMKgwqDCoA0KY3B1Mjphc3QNCsKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoA0KY3B1Mzphc3QNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCAxMg0KY3B1MDpwcmVlbQ0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAxMzYNCmNwdTI6cHJl ZW0NCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA5MQ0KY3B1MzpwcmVlbQ0KwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgDQpjcHUwOmhhcmRjDQoNCk5vdGUgdGhlICI0OTVrIiBu dW1iZXIuwqAgVGhhdCdzIHJlYWw7IG9uIHRoZSB1bml0IHRoYXQgaXMgTk9UDQptaXNiZWhh dmluZyB0aGF0J3Mgbm90IHRoZXJlLCBhbmQgbmVpdGhlciBhcmUgdGhlIG1pc3NlZCBpbnRl cnJ1cHQNCmNvbXBsYWludHMuDQoNCkJ1dCBhZ2FpbiwgbGFzdCBuaWdodCB0aGUgb25lIHRo YXQgdGhpcyBtb3JuaW5nIGlzIE5PVCBtaXNiZWhhdmluZyBXQVMsDQphbmQgd2FzIHNob3dp bmcgdGhlIGV4YWN0IHNhbWUgdGhpbmcuDQoNClNvIHRoaXMgbG9va3MgbGlrZSBzb21ldGhp bmcgdGhhdCBpcyBub3QgYmVpbmcgaW5pdGlhbGl6ZWQgcHJvcGVydHkgYXQNCmJvb3QgdGlt ZSwgYW5kIHNvbWV0aW1lcyBob3dldmVyIGl0IGNvbWVzIHVwIGNhdXNlcyB0cm91YmxlLCBh bmQgb3RoZXINCnRpbWVzIGl0IGRvZXMgbm90IC0tIHdoaWNoIGlzIGxpa2VseSB0byBtYWtl IGl0IGEgImxvdCIgb2YgZnVuIHRvIGZpbmQuDQoNClNwZWNpZmljYWxseSwgaWYgSSBoYWQg dG8gZ3Vlc3MgaXRzIHRoYXQgdGhlcmUncyBhbiBpbnRlcnJ1cHQgc291cmNlDQp0aGF0IGlz IGF0dGFjaGVkIHRvIHRoZSBDUFUgYnV0IHRoZXJlJ3Mgbm8gaGFuZGxlciBmb3IgaXQsIGFu ZCBpZiBpdA0KdHJpZ2dlcnMgYW5kIGlzIG5vdCBhY2tub3dsZWRnZWQgaXQgS0VFUFMgdHJp Z2dlcmluZy7CoCBUaGUgcXVlc3Rpb24gaXMNCi0tIHdoYXQgaXMgaXQgYW5kIHdoeSBpcyBp dCAib24iPw0KDQpUaGUgdWJvb3QgKGFuZCB0aHVzIGltcGxpZWQgRFRTKSBwYWNrYWdlIHRo YXQgZ2V0cyBpbmNsdWRlZCBoZXJlIG9uIHRoZQ0KYnVpbGQgbWFjaGluZSBpczoNCg0KdS1i b290LXJwaTItMjAxOS4wMcKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgQ3Jvc3MtYnVpbGQgZGFz IHUtYm9vdCBmb3IgbW9kZWwgcnBpMg0KDQppZiB0aGF0IG1hdHRlcnMgLS0gYW5kIGl0IG1p Z2h0Li4uLi4NCg0KSSdtIGdvaW5nIHRvIGxlYXZlIGJvdGggcnVubmluZzsgaWYgYW55b25l IGhhcyBpZGVhcyBvZiB0aGluZ3MgSSBjYW4NCnBva2UgdG8gdHJ5IHRvIGZpZ3VyZSBvdXQg d2h5IHRoZSBvbmUgdGhhdCBpcyBkb2luZyBpdCBpcywgb3IgdGhlIG90aGVyDQp3YXkgYXJv dW5kLCBsZXQgbWUga25vdyBhbmQgSSdsbCBkdW1wL3Bva2Uvd2hhdGV2ZXIgdG8gdHJ5IHRv IGZpbmQgdGhlDQphbnN3ZXIgdG8gdGhpcy7CoCBJJ2Qgc3BlY2lmaWNhbGx5IGxpa2UgdG8g a25vdyB3aHkgInZtc3RhdCAtaSIgZG9lc24ndA0Kc2hvdyB0aGUgc291cmNlIG9mIHRoYXQg cmlkaWN1bG91cyByYXRlIGludGVycnVwdCBzdG9ybSAod2hpY2ggSVMgcmVhbCwNCmFzIHRo ZSBDUFUgbG9hZCBpcyByZWFsKSBidXQgInN5c3RhdCAtdm0iIGRvZXMuDQoNCi0tIA0KS2Fy bCBEZW5uaW5nZXINCmthcmxAZGVubmluZ2VyLm5ldCA8bWFpbHRvOmthcmxAZGVubmluZ2Vy Lm5ldD4NCi9UaGUgTWFya2V0IFRpY2tlci8NCi9bUy9NSU1FIGVuY3J5cHRlZCBlbWFpbCBw cmVmZXJyZWRdLw0K --------------ms050906090601090507070504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwMzI1MTYzMzMy WjBPBgkqhkiG9w0BCQQxQgRAvfndta1Llo+ucPNHLYwfjPVVL/tfggytFU1yqrDdEp5Vd9SW RR/lomgCbppKvDlb1EjZ1DLxAutbEBF6MRxfxTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgCViVcONtV9X9ZGHFN2pU46DPFdQB3ErscCb7Fbo+OOjljDNS6BB0tHP00w6FIPagsr RSrXz5lIZurP46IRGQJLI830AwOZEePxtNFKJM3QIeaoh4A4KSbVwzvC2cm+JKKw/TxNAMcj 451cMUEdBmh+q0tIAgZWR0QBp2L4X2AW1zg4H4OBzqsOjqite760dYD+PI1LH7QJulFE7NYn obzmW//bhzgno0d1V5+DtCizSRzev8KRwMnkIQMaUV75w1KXhdPVndMJubFfLJxLqIUvfzk2 SnlBAhW6FpKdq62X942/SiPQisGRU5Z5WD3/CUPBO/30e3EfRoBZtbqKKHYHFmdsU3w5GOiC X3+FDUMDvsEuVugl8LwGG+MzEvSj6+W88im0GoBgGsGVhDTzd5DrB0l85K72kgv7pDoKACzl 0ED2koc7YFwjwjZet93Cmm6402gGa04Th8Yvr4DW+lHJro/MTzNHdAUICAZ5ojVqVAeX/1Ni lYkDYudTsb7I8jCXzULYJPnUYVbu8Bs+M0GNgsumBrqlLk3Fiuxi9WFqA9yjaB5pC6I5caDS pI0CsNnPzUqzk/UMXcAjSHtx68v+UgMzIyO12sAjUehdYu7DPe0ZpkHvZj/3SnBALMAFTacN IFCm3YEGlafNx+7ZZZiFRHjQAsjiRIhqt9AUBkSKZAAAAAAAAA== --------------ms050906090601090507070504-- From owner-freebsd-arm@freebsd.org Mon Mar 25 16:48:38 2019 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 3FEBE1545822 for ; Mon, 25 Mar 2019 16:48:38 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 062FA74F20; Mon, 25 Mar 2019 16:48:36 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id x2PGmWME089710 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Mar 2019 17:48:33 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1553532514; bh=AVIykZnvMTHSDB67JoRRe4xX66NvoztKZVqKNJq+cxU=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=FtpQd7Lub2XB2OtAPdr4HYIED8wkLh3s/6Cxvw/in3zTOFw22v4pVbTdHRr0n3cYu DHCiEzCBu7gCixmfFj/qxjcyErI8gY0rtcl1Uw94ya/lFMBhwgrGATnOxDNoDP935x VpSFmyjfLq6N4cjBpOv8Uo/e49frlbmgJdEGJZ7s= Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id x2PGmSj8032646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Mar 2019 17:48:28 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id x2PGmSnD090539; Mon, 25 Mar 2019 17:48:28 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id x2PGmRDs090538; Mon, 25 Mar 2019 17:48:27 +0100 (CET) (envelope-from ticso) Date: Mon, 25 Mar 2019 17:48:27 +0100 From: Bernd Walter To: Karl Denninger Cc: Ian Lepore , "freebsd-arm@freebsd.org" Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] Message-ID: <20190325164827.GL57400@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> <20190319161423.GH57400@cicely7.cicely.de> <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> <40f57de2-2b25-3981-a416-b9958cc97636@denninger.net> <669892ac3fc37b0843a156c0ab102316829103fd.camel@freebsd.org> <663f2566-b035-7011-70eb-4163b41e6e55@denninger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <663f2566-b035-7011-70eb-4163b41e6e55@denninger.net> X-Operating-System: FreeBSD cicely7.cicely.de 12.0-STABLE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-Rspamd-Queue-Id: 062FA74F20 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cicely.de header.s=default header.b=FtpQd7Lu X-Spamd-Result: default: False [-2.34 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[ticso@cicely.de]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[cicely.de:+]; MX_GOOD(-0.01)[cached: mx1.bwct.de]; NEURAL_HAM_SHORT(-0.71)[-0.708,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:21461, ipnet:195.149.99.0/24, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.85)[-0.851,0]; R_DKIM_ALLOW(-0.20)[cicely.de:s=default]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.97)[-0.972,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cicely.de]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.99.149.195.list.dnswl.org : 127.0.20.0]; R_SPF_NA(0.00)[]; IP_SCORE(-0.00)[country: DE(-0.01)] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 16:48:38 -0000 On Mon, Mar 25, 2019 at 11:33:32AM -0500, Karl Denninger wrote: > > > What do you mean by an insane rate? It's normal for the usb controller > > to be showing around thousands of int/sec. Despite what seems like a > > high rate, even on an on rpi-b it uses under 2% cpu to service that. > > > > root@rpi:~ # vmstat -i > > interrupt total rate > > intc0,2: vchiq0 2 0 > > intc0,11: systimer0 10103206 1110 > > intc0,17:-x_dwcotg0 218596055 24007 > > intc0,28: bcm_dma0 834 0 > > intc0,61: iichb0 5778 1 > > intc0,65: uart0 1817 0 > > intc0,70:-dhci_bcm0 172 0 > > Total 228707864 25118 > > > > -- Ian > > The story gets more odd. > > The same *physical* unit that I saw this on last night with no I2c > device connected I restarted this morning -- changing NOTHING -- and it > disappeared. > > But -- on another unit it's still there (I haven't shut down, pulled > power and restarted that one.) > > vmstat -i on both doesn't show anything all that odd: > misbehaving that's not there, and neither are the missed interrupt > complaints. > > But again, last night the one that this morning is NOT misbehaving WAS, > and was showing the exact same thing. > > So this looks like something that is not being initialized property at > boot time, and sometimes however it comes up causes trouble, and other > times it does not -- which is likely to make it a "lot" of fun to find. By causing trouble - do you mean it doesn't work? I noticed that my system has this message: nxprtc0: RTC clock not running Warning: bad time from time-of-day clock, system time will not be set accurately This shouldn't happen, but I wonder if the iic communication works at all. I likely wouldn't notice if the rtc failed. Maybe there was an initial problem at start as you said. Will reboot it and see what happens. After a reboot the message about the rtc is gone. Have to wait at least a day to see if the Spurious are gone too. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Mon Mar 25 16:52:32 2019 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 AD51B1545C8C for ; Mon, 25 Mar 2019 16:52:32 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (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 B604475390 for ; Mon, 25 Mar 2019 16:52:31 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1553532750; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=jjeQCh75JI7wi5M8FnN4ldD+UOZPyzmXNmDXfaZ9KbC1+nL1II6tg/s5+/rKujY9CcgmrXzsUt6ug LFMaV0+aE0Gm/R6HQ9ioS0uNxESnKzjxgKK+wwnpMQaBrRaB6jawXxs/W6iXAEaZqzMx86SOcxSrcq chbppijwI1HADCYXvPYLkhUayJhUhMdEYBQMKFF6LLC3YDCFX0KlKbIjHK2PrZhUy/uNTUgR+NSo73 KeBMNu2t9ztFSLgBArgWdwZntrdiH8rjEoPTDWvy/JxSWFq7VhxGG5C5EtE5mzrIaLJe6mWsvsOYLo A4S3BkTQ1xFQw6UNPkFGYudB9OEkiAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=cTCxDwabceLeGFAsONz+j863+cFmHDghwdG3xf6ppYA=; b=V1zNvgqSAUi5VUKgDWZErMbIQ5FE2UOV1RWC95CfdbZMa1wSFfpz9l2CiTQ59YMOo6hYVH7tEae9L tib6dAVR2/sBVdVqVYIwq/cRBTjvTCh8xFeN7KL9t9ErNrotTBsGPfqGk2peV8BT3Su9G4FClrq8qq 8HUwP3RuQ4BdxTU0WzjHpGDkLx8GtmFVDltOU6ofqnzuw+l0CiWo4InFbEB15s9Iv8mNW4TEA+mDuN Rq7xDnMeIqIRjI3clw+KTgzpSHHivOFRKoJUIWXJ+GcDCTdtf76Q3Siw60HrchbktqLZ7JrewoSxyi V006lpMp8GXwnYCctwqooaAGCG7xf5w== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=cTCxDwabceLeGFAsONz+j863+cFmHDghwdG3xf6ppYA=; b=MlMUS7enSooZJGGkEnCDxI01VY0SfhV7izS5jml7lfnoUTibpbO6hth5vFvfk7vfep33q7+M9ZH/O CPkAZid2e7iPq3vpgloNooRs9UcXFqNQxyAft9tKV5uQdM1Wej0TflQDe6Si5iLMmh7AFdfae2keCS Dk8voIA+4YlT9fwGYNXYk53ngTj28i58/b8ON9uB3zFLChv/NyPwpfUagapHbuDXQ9oBIuHATtkniP Q66yag+IRqgRvfh4CqrpTR0/egIVFzFA1yVgGIUYRnVqfNpSmPGJVEaYwSt/iDc4ji4t8JOcPlOdEQ g4nxsRgmWngEAVFA54mDFFQ285F/XSQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: 5eb25d1b-4f1e-11e9-9bb1-1f29e4676f89 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 outbound3.ore.mailhop.org (Halon) with ESMTPSA id 5eb25d1b-4f1e-11e9-9bb1-1f29e4676f89; Mon, 25 Mar 2019 16:52:29 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x2PGqQfe083617; Mon, 25 Mar 2019 10:52:26 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] From: Ian Lepore To: ticso@cicely.de, Karl Denninger Cc: "freebsd-arm@freebsd.org" Date: Mon, 25 Mar 2019 10:52:26 -0600 In-Reply-To: <20190325164827.GL57400@cicely7.cicely.de> References: <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> <20190319161423.GH57400@cicely7.cicely.de> <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> <40f57de2-2b25-3981-a416-b9958cc97636@denninger.net> <669892ac3fc37b0843a156c0ab102316829103fd.camel@freebsd.org> <663f2566-b035-7011-70eb-4163b41e6e55@denninger.net> <20190325164827.GL57400@cicely7.cicely.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: B604475390 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 16:52:32 -0000 On Mon, 2019-03-25 at 17:48 +0100, Bernd Walter wrote: > On Mon, Mar 25, 2019 at 11:33:32AM -0500, Karl Denninger wrote: > > > > > What do you mean by an insane rate? It's normal for the usb > > > controller > > > to be showing around thousands of int/sec. Despite what seems > > > like a > > > high rate, even on an on rpi-b it uses under 2% cpu to service > > > that. > > > > > > root@rpi:~ # vmstat -i > > > interrupt total rate > > > intc0,2: vchiq0 2 0 > > > intc0,11: systimer0 10103206 1110 > > > intc0,17:-x_dwcotg0 218596055 24007 > > > intc0,28: bcm_dma0 834 0 > > > intc0,61: iichb0 5778 1 > > > intc0,65: uart0 1817 0 > > > intc0,70:-dhci_bcm0 172 0 > > > Total 228707864 25118 > > > > > > -- Ian > > > > The story gets more odd. > > > > The same *physical* unit that I saw this on last night with no I2c > > device connected I restarted this morning -- changing NOTHING -- > > and it > > disappeared. > > > > But -- on another unit it's still there (I haven't shut down, > > pulled > > power and restarted that one.) > > > > vmstat -i on both doesn't show anything all that odd: > > misbehaving that's not there, and neither are the missed interrupt > > complaints. > > > > But again, last night the one that this morning is NOT misbehaving > > WAS, > > and was showing the exact same thing. > > > > So this looks like something that is not being initialized property > > at > > boot time, and sometimes however it comes up causes trouble, and > > other > > times it does not -- which is likely to make it a "lot" of fun to > > find. > > By causing trouble - do you mean it doesn't work? > I noticed that my system has this message: > nxprtc0: RTC clock not running > Warning: bad time from time-of-day clock, system time will not be set > accurately > This shouldn't happen, but I wonder if the iic communication works at > all. > I likely wouldn't notice if the rtc failed. > Maybe there was an initial problem at start as you said. > Will reboot it and see what happens. > After a reboot the message about the rtc is gone. > Have to wait at least a day to see if the Spurious are gone too. > That's not a symptom of i2c comms failure, it's a symptom of a dead rtc battery. The driver has to communicate with the rtc chip to determine that the oscillator was stopped. After a reboot all is well, because the rtc oscillator gets started when the time is written to the chip, and it keeps running through a reboot and only stops on a power cycle. -- Ian From owner-freebsd-arm@freebsd.org Mon Mar 25 16:58:31 2019 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 E2D9C1545DFA for ; Mon, 25 Mar 2019 16:58:30 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 4C2AB754A0; Mon, 25 Mar 2019 16:58:29 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id AFDFA211098; Mon, 25 Mar 2019 12:58:28 -0400 (EDT) Received: from [192.168.10.14] (D4.Denninger.Net [192.168.10.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 3DF9CD0CD0; Mon, 25 Mar 2019 11:58:28 -0500 (CDT) Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] To: ticso@cicely.de Cc: Ian Lepore , "freebsd-arm@freebsd.org" References: <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> <20190319161423.GH57400@cicely7.cicely.de> <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> <40f57de2-2b25-3981-a416-b9958cc97636@denninger.net> <669892ac3fc37b0843a156c0ab102316829103fd.camel@freebsd.org> <663f2566-b035-7011-70eb-4163b41e6e55@denninger.net> <20190325164827.GL57400@cicely7.cicely.de> From: Karl Denninger Openpgp: preference=signencrypt Autocrypt: addr=karl@denninger.net; prefer-encrypt=mutual; keydata= mQINBFIX1zsBEADRcJfsQUl9oFeoMfLPJ1kql+3sIaYx0MfJAUhV9LnbWxr0fsWCskM1O4cV tHm5dqPkuPM4Ztc0jLotD1i9ubWvCHOlkLGxFOL+pFbjA+XZ7VKsC/xWmhMwJ3cM8HavK2OV SzEWQ/AEYtMi04IzGSwsxh/5/5R0mPHrsIomV5SbuiI0vjLuDj7fo6146AABI1ULzge4hBYW i/SHrqUrLORmUNBs6bxek79/B0Dzk5cIktD3LOfbT9EAa5J/osVkstMBhToJgQttaMIGv8SG CzpR/HwEokE+7DP+k2mLHnLj6H3kfugOF9pJH8Za4yFmw//s9cPXV8WwtZ2SKfVzn1unpKqf wmJ1PwJoom/d4fGvQDkgkGKRa6RGC6tPmXnqnx+YX4iCOdFfbP8L9rmk2sewDDVzHDU3I3ZZ 8hFIjMYM/QXXYszRatK0LCV0QPZuF7LCf4uQVKw1/oyJInsnH7+6a3c0h21x+CmSja9QJ+y0 yzgEN/nM89d6YTakfR+1xkYgodVmMy/bS8kmXbUUZG/CyeqCqc95RUySjKT2ECrf9GhhoQkl +D8n2MsrAUSMGB4GQSN+TIq9OBTpNuvATGSRuF9wnQcs1iSry+JNCpfRTyWp83uCNApe6oHU EET4Et6KDO3AvjvBMAX0TInTRGW2SQlJMuFKpc7Dg7tHK8zzqQARAQABtCNLYXJsIERlbm5p bmdlciA8a2FybEBkZW5uaW5nZXIubmV0PokCPAQTAQIAJgUCUhfXOwIbIwUJCWYBgAYLCQgH AwIEFQIIAwQWAgMBAh4BAheAAAoJEG6/sivc5s0PLxQP/i6x/QFx9G4Cw7C+LthhLXIm7NSH AtNbz2UjySEx2qkoQQjtsK6mcpEEaky4ky6t8gz0/SifIfJmSmyAx0UhUQ0WBv1vAXwtNrQQ jJd9Bj6l4c2083WaXyHPjt2u2Na6YFowyb4SaQb83hu/Zs25vkPQYJVVE0JX409MFVPUa6E3 zFbd1OTr3T4yNUy4gNeQZfzDqDS8slbIks2sXeoJrZ6qqXVI0ionoivOlaN4T6Q0UYyXtigj dQvvhMt0aNowKFjRqrmSDRpdz+o6yg7Mp7qEZ1V6EZk8KqQTH6htpCTQ8i79ttK4LG6bstSF Re6Fwq52nbrcANrcdmtZXqjo+SGbUqJ8b1ggrxAsJ5MEhRh2peKrCgI/TjQo+ZxfnqEoR4AI 46Cyiz+/lcVvlvmf2iPifS3EEdaH3Itfwt7MxFm6mQORYs6skHDw3tOYB2/AdCW6eRVYs2hB RMAG4uwApZfZDKgRoE95PJmQjeTBiGmRPcsQZtNESe7I7EjHtCDLwtJqvD4HkDDQwpzreT6W XkyIJ7ns7zDfA1E+AQhFR6rsTFGgQZRZKsVeov3SbhYKkCnVDCvb/PKQCAGkSZM9SvYG5Yax 8CMry3AefKktf9fqBFg8pWqtVxDwJr56dhi0GHXRu3jVI995rMGo1fLUG5fSxiZ8L5sAtokh 9WFmQpyl Message-ID: <3db9cf8a-68ee-e339-67bf-760ee51464fd@denninger.net> Date: Mon, 25 Mar 2019 11:58:27 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <20190325164827.GL57400@cicely7.cicely.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060009050305080409010209" X-Rspamd-Queue-Id: 4C2AB754A0 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.35 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: px.denninger.net]; NEURAL_HAM_SHORT(-0.83)[-0.832,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-2.30)[ip: (-9.88), ipnet: 104.236.64.0/18(-3.60), asn: 14061(2.02), country: US(-0.07)]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:+]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[197.57.1.68.zen.spamhaus.org : 127.0.0.11]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; DMARC_NA(0.00)[denninger.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 16:58:31 -0000 This is a cryptographically signed message in MIME format. --------------ms060009050305080409010209 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/25/2019 11:48, Bernd Walter wrote: > On Mon, Mar 25, 2019 at 11:33:32AM -0500, Karl Denninger wrote: >>> What do you mean by an insane rate? It's normal for the usb controll= er >>> to be showing around thousands of int/sec. Despite what seems like a= >>> high rate, even on an on rpi-b it uses under 2% cpu to service that. >>> >>> root@rpi:~ # vmstat -i >>> interrupt total rate >>> intc0,2: vchiq0 2 0 >>> intc0,11: systimer0 10103206 1110 >>> intc0,17:-x_dwcotg0 218596055 24007 >>> intc0,28: bcm_dma0 834 0 >>> intc0,61: iichb0 5778 1 >>> intc0,65: uart0 1817 0 >>> intc0,70:-dhci_bcm0 172 0 >>> Total 228707864 25118 >>> >>> -- Ian >> The story gets more odd. >> >> The same *physical* unit that I saw this on last night with no I2c >> device connected I restarted this morning -- changing NOTHING -- and i= t >> disappeared. >> >> But -- on another unit it's still there (I haven't shut down, pulled >> power and restarted that one.) >> >> vmstat -i on both doesn't show anything all that odd: >> misbehaving that's not there, and neither are the missed interrupt >> complaints. >> >> But again, last night the one that this morning is NOT misbehaving WAS= , >> and was showing the exact same thing. >> >> So this looks like something that is not being initialized property at= >> boot time, and sometimes however it comes up causes trouble, and other= >> times it does not -- which is likely to make it a "lot" of fun to find= =2E > By causing trouble - do you mean it doesn't work? > I noticed that my system has this message: > nxprtc0: RTC clock not running > Warning: bad time from time-of-day clock, system time will not be set a= ccurately > This shouldn't happen, but I wonder if the iic communication works at a= ll. > I likely wouldn't notice if the rtc failed. > Maybe there was an initial problem at start as you said. > Will reboot it and see what happens. > After a reboot the message about the rtc is gone. > Have to wait at least a day to see if the Spurious are gone too. In both cases on my boxes everything is working, but that's not unexpected because of the way my code works (it dynamically detects a change in configuration in that if it tries to open the I2c bus when there's a configuration file for devices on it, and it fails, it will try again in a few seconds -- and if you remove the config then it will shut down the I/O path in a short while and stop.) On the units that exhibit the problem the load average is 1.0 + whatever is real *and* the crazy interrupt rate is present.=C2=A0 On the ones that= are not neither is the case; the native and real load average is present and the interrupt rate is normal. In the case of the unit that the problem showed up on and then disappeared, however, while there's an I2c config defined there's no device connected to it on my bench. But I suspect this is something banging the interrupts on the CPU that is not attached to anything in the code, and the reason I suspect that is that on a given boot it either happens or not, and if it does then nothing I can do will make it stop -- and likewise, nothing I can do will make it start if it doesn't on boot.=C2=A0 That implies that whateve= r it is it's not code-specific nor .ko-loaded specific either, in that if it was related specifically to an I2c device being talked to actively then when I killed the code that was using I2c or booted without the device connected (or never started the code that attempted to probe the bus and attach to the device in question) it wouldn't do it at all -- but that's not true. The one that stopped doing it I then attached both an I2c device that it was looking for and also connected a "modem-style" device (which caused umodem.ko to autoload, as expected) and it came up as well, without a problem -- and without triggering the mad interrupt storm. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060009050305080409010209 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwMzI1MTY1ODI3 WjBPBgkqhkiG9w0BCQQxQgRAomRcAjJ7UI0mBuUiUxoM0ZhbLHehhQjGdGEJqjHplVW5HvbD QCZHdHGm8pa2a8EvWQ7VwMr1+4sMvbtkGDmWsjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgBnLDTt3I7IpmrUjdTdXXUCHJ7PCQJ/lz43zC/MZY32zsPqJtlzz+I0iP3O3t2Ulmll n0I3yy1XEDf9ERLkQEy8msWhsCzvxoHFkvb2/EEy6EqgwxlQ4hyKrpMeaBaR/2qpltVMuCAZ yaABGck7v0IuW2PtxhkWIcdI7Tpg3AiicPgYZFvBAxveE2BUFIhXteh1Gf+7Zl9O9X4BtFeX Kn/Dh7VlaIeng+oc/LXdjP87K5llro37HFKZHrWrZHWockIMkpkhpARFkLH2cu5i/zGfVUuP fwG3AGmELBa2mRAI+WH+q2QjsVlBPPT6qNEkadI5o9/BTwJqlgN2h7Bc0DOULs/duI5SNd4R 4/U8Gzku9OhDHs7jQ6wwBatUyk8l2rA2F8EAhnY7ll5pqFz6SBXpeCqErBo7pEVnaQy7e/HD dpxDl+kQTtP3SBDgyd8sdaDt6b/r8129R82v03P2c6lOmm5Eqeh9M7rEfKHRL3TZZOLzDuWc qYjIjL30yV7UuLR4DUiRAA+TeG9kSlBkrfi03a+t5nQ2LVlAm6maY8BhNJ3s32sIQexMWy3a hmKKfC7X9fNOox0x0+JQHmP4AawoCDqO/vgzt7/QnujNrTKK/OJxtCGnUf1zD+ZUAL0+ULoc cXJLDAdc/BziHU6Sv7zT7NS4CxTZlJY2jfJUJtbiOgAAAAAAAA== --------------ms060009050305080409010209-- From owner-freebsd-arm@freebsd.org Mon Mar 25 17:05:44 2019 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 4C31815462B9 for ; Mon, 25 Mar 2019 17:05:44 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DDD075D0B; Mon, 25 Mar 2019 17:05:43 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id x2PH5dms090208 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Mar 2019 18:05:40 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1553533540; bh=C4Aog0RayzGnl9CKJkO6QOH+QVrLTsfe2UomRyJmoRU=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=k0YXLrenl0N1PnV4P6hn1OWKGB65WNVChi4QEOlVQKTybihlNPYW0fFxZ7roVZHR3 b9c4Bj+i3go3IBKhFVeGy95Hn1YqOx+NnJJT3UlNydPZ6pW3gSe0hSblHwzcR9Yq8v n9VwCep/XEzSgh5iRQ8AqZ9eioxB+nCs23w01oWw= Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id x2PH5Zsm033219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Mar 2019 18:05:35 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id x2PH5Z2R090651; Mon, 25 Mar 2019 18:05:35 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id x2PH5ZH6090650; Mon, 25 Mar 2019 18:05:35 +0100 (CET) (envelope-from ticso) Date: Mon, 25 Mar 2019 18:05:35 +0100 From: Bernd Walter To: Ian Lepore Cc: ticso@cicely.de, Karl Denninger , "freebsd-arm@freebsd.org" Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] Message-ID: <20190325170534.GM57400@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20190319161423.GH57400@cicely7.cicely.de> <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> <40f57de2-2b25-3981-a416-b9958cc97636@denninger.net> <669892ac3fc37b0843a156c0ab102316829103fd.camel@freebsd.org> <663f2566-b035-7011-70eb-4163b41e6e55@denninger.net> <20190325164827.GL57400@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 12.0-STABLE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-Rspamd-Queue-Id: 7DDD075D0B X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cicely.de header.s=default header.b=k0YXLren X-Spamd-Result: default: False [-1.80 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[ticso@cicely.de]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[cicely.de:+]; MX_GOOD(-0.01)[cached: mx1.bwct.de]; NEURAL_HAM_SHORT(-0.15)[-0.153,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:21461, ipnet:195.149.99.0/24, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.865,0]; R_DKIM_ALLOW(-0.20)[cicely.de:s=default]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.97)[-0.973,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cicely.de]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.99.149.195.list.dnswl.org : 127.0.20.0]; R_SPF_NA(0.00)[]; IP_SCORE(-0.00)[country: DE(-0.01)] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 17:05:44 -0000 On Mon, Mar 25, 2019 at 10:52:26AM -0600, Ian Lepore wrote: > On Mon, 2019-03-25 at 17:48 +0100, Bernd Walter wrote: > > On Mon, Mar 25, 2019 at 11:33:32AM -0500, Karl Denninger wrote: > > > > > > > What do you mean by an insane rate? It's normal for the usb > > > > controller > > > > to be showing around thousands of int/sec. Despite what seems > > > > like a > > > > high rate, even on an on rpi-b it uses under 2% cpu to service > > > > that. > > > > > > > > root@rpi:~ # vmstat -i > > > > interrupt total rate > > > > intc0,2: vchiq0 2 0 > > > > intc0,11: systimer0 10103206 1110 > > > > intc0,17:-x_dwcotg0 218596055 24007 > > > > intc0,28: bcm_dma0 834 0 > > > > intc0,61: iichb0 5778 1 > > > > intc0,65: uart0 1817 0 > > > > intc0,70:-dhci_bcm0 172 0 > > > > Total 228707864 25118 > > > > > > > > -- Ian > > > > > > The story gets more odd. > > > > > > The same *physical* unit that I saw this on last night with no I2c > > > device connected I restarted this morning -- changing NOTHING -- > > > and it > > > disappeared. > > > > > > But -- on another unit it's still there (I haven't shut down, > > > pulled > > > power and restarted that one.) > > > > > > vmstat -i on both doesn't show anything all that odd: > > > misbehaving that's not there, and neither are the missed interrupt > > > complaints. > > > > > > But again, last night the one that this morning is NOT misbehaving > > > WAS, > > > and was showing the exact same thing. > > > > > > So this looks like something that is not being initialized property > > > at > > > boot time, and sometimes however it comes up causes trouble, and > > > other > > > times it does not -- which is likely to make it a "lot" of fun to > > > find. > > > > By causing trouble - do you mean it doesn't work? > > I noticed that my system has this message: > > nxprtc0: RTC clock not running > > Warning: bad time from time-of-day clock, system time will not be set > > accurately > > This shouldn't happen, but I wonder if the iic communication works at > > all. > > I likely wouldn't notice if the rtc failed. > > Maybe there was an initial problem at start as you said. > > Will reboot it and see what happens. > > After a reboot the message about the rtc is gone. > > Have to wait at least a day to see if the Spurious are gone too. > > > > That's not a symptom of i2c comms failure, it's a symptom of a dead rtc > battery. The driver has to communicate with the rtc chip to determine > that the oscillator was stopped. After a reboot all is well, because > the rtc oscillator gets started when the time is written to the chip, > and it keeps running through a reboot and only stops on a power cycle. Agreed, but there is a story behind. The board had a design flaw in that it drained the battery over the pullups into the Pi when the Pi was powered down. I fixed that circuit and did power down tests as well. Don't know if the previous boot was after power down, but it is unlikely that the battery is dead again and if it was a power down then it was a rather short one. It is not a test system, I run it 24/7 as a local ntp server since about only 1-2 months. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Mon Mar 25 17:05:50 2019 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 A447615462DD for ; Mon, 25 Mar 2019 17:05:50 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1.eu.mailhop.org (outbound1.eu.mailhop.org [52.28.251.132]) (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 DECC275D18 for ; Mon, 25 Mar 2019 17:05:49 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1553533548; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=LrNWZnmeD8tNH2M/CM+d99eslG8yy2PXkZTf3YvHEX7m9L1gLWk+erTC1H9dMkt+Bys+aiUouufNG A7MGdydvVGTROunKFB248lusejthqQYB/HnQs67C+Wwow5d3Cp8oG6K0y/bbljWc9gdsEXSFqE2c9m eRiTP2V+B4knBBN/eW/46iXFBVTOahscxKUgFOVsbamlSIWSpNT4zdncAkQNyxB37RvPhjhVd7NIXc 048zZVQAB6gBnbHaeDhLsWWEJt55KDQ86e8x6e7YtcLueMc0tPZwHxBwakr+ocOCPKk/92RlETeYgv cC0jCYb48dFtlrajjq/pnBfgQfq8+4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=lnJMAY4sZtBAxtOe/0VhFS/cHVTY67mA8QIwuFiGlBo=; b=oqElSqXptTmq1ifmcTQK2AC2O7FiLTWCoOK8t/U9F8fTY9jQvharAiQ2J9ddZGa7sdFWg6tnc4bk/ wQA6wJY5oQE8mDMfsUVYqXMnIIGBVe3sy7qstO4PpGxiTc3QjOkf3lGFOHoit1h2rDkcqxmt5KSDJO djn6BIqlPritsfNo0pL2HFiyshg+VLU1ejMw1YA8miRJBXBDixBm+SgrtaaLago/1k+6nj1paXTFB5 DKjUT8rWdVRY4j38D3H6iDl1Lp3hluE5t39my+lWW3Y2SDwtPg+/C0xnIqR8aXGeFjpkwK/1DfWXku lDGUSxbi13zOQuu5f8IioxucL5ooaMQ== ARC-Authentication-Results: i=1; outbound3.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=lnJMAY4sZtBAxtOe/0VhFS/cHVTY67mA8QIwuFiGlBo=; b=aIwkWrXkEdhrclQf2m8jd3IEJ3TPaN7AdliWvJGj578cDv55OwBcZNzEnd6/57V8lBXWX/H7q6JPp jWGzIKn6uD58A2N6S9aSm/xuc8Gz0W4q7M7jWKb1mO1RMynbhmDzJsbyjc4QvEwyyFUXOr7iOPSA+l J85y2xuHB2uViqp9UIWu8sZkX6NrHFz93DtOnAU5xTLx+PKSOlixhTEUumg/QlXZbgJ6OJw5UfnQwR xb+0eZZaOGp8KMXq5/uoggxdIw4sR524EumrMBMyZnI0aDaCVyMWu8+XA+H8vQKkaq39LDbo7XVn2L oDLiIhsGJNT7CZ86pCAZG7lbIpnNxfg== X-MHO-RoutePath: aGlwcGll X-MHO-User: 3940bd38-4f20-11e9-908b-352056dbf2de 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 outbound3.eu.mailhop.org (Halon) with ESMTPSA id 3940bd38-4f20-11e9-908b-352056dbf2de; Mon, 25 Mar 2019 17:05:44 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x2PH5g3b083679; Mon, 25 Mar 2019 11:05:42 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] From: Ian Lepore To: Karl Denninger , ticso@cicely.de Cc: "freebsd-arm@freebsd.org" Date: Mon, 25 Mar 2019 11:05:42 -0600 In-Reply-To: <3db9cf8a-68ee-e339-67bf-760ee51464fd@denninger.net> References: <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> <20190319161423.GH57400@cicely7.cicely.de> <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> <40f57de2-2b25-3981-a416-b9958cc97636@denninger.net> <669892ac3fc37b0843a156c0ab102316829103fd.camel@freebsd.org> <663f2566-b035-7011-70eb-4163b41e6e55@denninger.net> <20190325164827.GL57400@cicely7.cicely.de> <3db9cf8a-68ee-e339-67bf-760ee51464fd@denninger.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: DECC275D18 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:16509, ipnet:52.28.0.0/16, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 17:05:50 -0000 On Mon, 2019-03-25 at 11:58 -0500, Karl Denninger wrote: > On 3/25/2019 11:48, Bernd Walter wrote: > > On Mon, Mar 25, 2019 at 11:33:32AM -0500, Karl Denninger wrote: > > > > What do you mean by an insane rate? It's normal for the usb > > > > controller > > > > to be showing around thousands of int/sec. Despite what seems > > > > like a > > > > high rate, even on an on rpi-b it uses under 2% cpu to service > > > > that. > > > > > > > > root@rpi:~ # vmstat -i > > > > interrupt total rate > > > > intc0,2: vchiq0 2 0 > > > > intc0,11: systimer0 10103206 1110 > > > > intc0,17:-x_dwcotg0 218596055 24007 > > > > intc0,28: bcm_dma0 834 0 > > > > intc0,61: iichb0 5778 1 > > > > intc0,65: uart0 1817 0 > > > > intc0,70:-dhci_bcm0 172 0 > > > > Total 228707864 25118 > > > > > > > > -- Ian > > > > > > The story gets more odd. > > > > > > The same *physical* unit that I saw this on last night with no > > > I2c > > > device connected I restarted this morning -- changing NOTHING -- > > > and it > > > disappeared. > > > > > > But -- on another unit it's still there (I haven't shut down, > > > pulled > > > power and restarted that one.) > > > > > > vmstat -i on both doesn't show anything all that odd: > > > misbehaving that's not there, and neither are the missed > > > interrupt > > > complaints. > > > > > > But again, last night the one that this morning is NOT > > > misbehaving WAS, > > > and was showing the exact same thing. > > > > > > So this looks like something that is not being initialized > > > property at > > > boot time, and sometimes however it comes up causes trouble, and > > > other > > > times it does not -- which is likely to make it a "lot" of fun to > > > find. > > > > By causing trouble - do you mean it doesn't work? > > I noticed that my system has this message: > > nxprtc0: RTC clock not running > > Warning: bad time from time-of-day clock, system time will not be > > set accurately > > This shouldn't happen, but I wonder if the iic communication works > > at all. > > I likely wouldn't notice if the rtc failed. > > Maybe there was an initial problem at start as you said. > > Will reboot it and see what happens. > > After a reboot the message about the rtc is gone. > > Have to wait at least a day to see if the Spurious are gone too. > > In both cases on my boxes everything is working, but that's not > unexpected because of the way my code works (it dynamically detects a > change in configuration in that if it tries to open the I2c bus when > there's a configuration file for devices on it, and it fails, it will > try again in a few seconds -- and if you remove the config then it > will > shut down the I/O path in a short while and stop.) > > On the units that exhibit the problem the load average is 1.0 + > whatever > is real *and* the crazy interrupt rate is present. On the ones that > are > not neither is the case; the native and real load average is present > and > the interrupt rate is normal. > > In the case of the unit that the problem showed up on and then > disappeared, however, while there's an I2c config defined there's no > device connected to it on my bench. > > But I suspect this is something banging the interrupts on the CPU > that > is not attached to anything in the code, and the reason I suspect > that > is that on a given boot it either happens or not, and if it does then > nothing I can do will make it stop -- and likewise, nothing I can do > will make it start if it doesn't on boot. That implies that whatever > it > is it's not code-specific nor .ko-loaded specific either, in that if > it > was related specifically to an I2c device being talked to actively > then > when I killed the code that was using I2c or booted without the > device > connected (or never started the code that attempted to probe the bus > and > attach to the device in question) it wouldn't do it at all -- but > that's > not true. > > The one that stopped doing it I then attached both an I2c device that > it > was looking for and also connected a "modem-style" device (which > caused > umodem.ko to autoload, as expected) and it came up as well, without a > problem -- and without triggering the mad interrupt storm. > Is the interrupt rate consistent from second to second? Running 'vmstat 1' for a while might be useful to see that. That many interrupts almost sounds like a line is floating, but if that were the case I'd expect a widely varying number of int/sec. If you build custom kernels, it might be helpful to apply r345475 locally... it will display partial device names instead of just '+' when the name doesn't fit in the vmstat output. -- Ian From owner-freebsd-arm@freebsd.org Mon Mar 25 17:09:57 2019 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 493C115464A4 for ; Mon, 25 Mar 2019 17:09:57 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A04D875F35; Mon, 25 Mar 2019 17:09:56 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id x2PH9r6R090308 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Mar 2019 18:09:54 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1553533794; bh=dE6Lb2ai2GPWy7/0rwfVevbpVDqPyAHJRq6bTo7VuqM=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=2T85IwY9nL610uQZ5EsfMlmab5vSO+1CJINppP+a50CMmkx4SozJNsJ/Ukkedn0xy MK2ecVOx3GoJN8KoJcTyOv29F7PYhdT5HtnDSfDt8EokS9MgihVVZY88UHfREXMl+h i74H/hymFWOp2QZv1vFpBEgxi1LmON2aWiVR+RfY= Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id x2PH9mTt033259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Mar 2019 18:09:48 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id x2PH9m3J090674; Mon, 25 Mar 2019 18:09:48 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id x2PH9mR4090673; Mon, 25 Mar 2019 18:09:48 +0100 (CET) (envelope-from ticso) Date: Mon, 25 Mar 2019 18:09:48 +0100 From: Bernd Walter To: Ian Lepore Cc: ticso@cicely.de, Karl Denninger , "freebsd-arm@freebsd.org" Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] Message-ID: <20190325170948.GN57400@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20190319161423.GH57400@cicely7.cicely.de> <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> <40f57de2-2b25-3981-a416-b9958cc97636@denninger.net> <669892ac3fc37b0843a156c0ab102316829103fd.camel@freebsd.org> <663f2566-b035-7011-70eb-4163b41e6e55@denninger.net> <20190325164827.GL57400@cicely7.cicely.de> <20190325170534.GM57400@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190325170534.GM57400@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 12.0-STABLE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-Rspamd-Queue-Id: A04D875F35 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cicely.de header.s=default header.b=2T85IwY9 X-Spamd-Result: default: False [-1.79 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[ticso@cicely.de]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[cicely.de:+]; MX_GOOD(-0.01)[cached: mx1.bwct.de]; NEURAL_HAM_SHORT(-0.14)[-0.144,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:21461, ipnet:195.149.99.0/24, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.86)[-0.858,0]; R_DKIM_ALLOW(-0.20)[cicely.de:s=default]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.97)[-0.973,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cicely.de]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.99.149.195.list.dnswl.org : 127.0.20.0]; R_SPF_NA(0.00)[]; IP_SCORE(-0.00)[country: DE(-0.01)] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 17:09:57 -0000 On Mon, Mar 25, 2019 at 06:05:35PM +0100, Bernd Walter wrote: > On Mon, Mar 25, 2019 at 10:52:26AM -0600, Ian Lepore wrote: > > On Mon, 2019-03-25 at 17:48 +0100, Bernd Walter wrote: > > > On Mon, Mar 25, 2019 at 11:33:32AM -0500, Karl Denninger wrote: > > > > > > > > > What do you mean by an insane rate? It's normal for the usb > > > > > controller > > > > > to be showing around thousands of int/sec. Despite what seems > > > > > like a > > > > > high rate, even on an on rpi-b it uses under 2% cpu to service > > > > > that. > > > > > > > > > > root@rpi:~ # vmstat -i > > > > > interrupt total rate > > > > > intc0,2: vchiq0 2 0 > > > > > intc0,11: systimer0 10103206 1110 > > > > > intc0,17:-x_dwcotg0 218596055 24007 > > > > > intc0,28: bcm_dma0 834 0 > > > > > intc0,61: iichb0 5778 1 > > > > > intc0,65: uart0 1817 0 > > > > > intc0,70:-dhci_bcm0 172 0 > > > > > Total 228707864 25118 > > > > > > > > > > -- Ian > > > > > > > > The story gets more odd. > > > > > > > > The same *physical* unit that I saw this on last night with no I2c > > > > device connected I restarted this morning -- changing NOTHING -- > > > > and it > > > > disappeared. > > > > > > > > But -- on another unit it's still there (I haven't shut down, > > > > pulled > > > > power and restarted that one.) > > > > > > > > vmstat -i on both doesn't show anything all that odd: > > > > misbehaving that's not there, and neither are the missed interrupt > > > > complaints. > > > > > > > > But again, last night the one that this morning is NOT misbehaving > > > > WAS, > > > > and was showing the exact same thing. > > > > > > > > So this looks like something that is not being initialized property > > > > at > > > > boot time, and sometimes however it comes up causes trouble, and > > > > other > > > > times it does not -- which is likely to make it a "lot" of fun to > > > > find. > > > > > > By causing trouble - do you mean it doesn't work? > > > I noticed that my system has this message: > > > nxprtc0: RTC clock not running > > > Warning: bad time from time-of-day clock, system time will not be set > > > accurately > > > This shouldn't happen, but I wonder if the iic communication works at > > > all. > > > I likely wouldn't notice if the rtc failed. > > > Maybe there was an initial problem at start as you said. > > > Will reboot it and see what happens. > > > After a reboot the message about the rtc is gone. > > > Have to wait at least a day to see if the Spurious are gone too. > > > > > > > That's not a symptom of i2c comms failure, it's a symptom of a dead rtc > > battery. The driver has to communicate with the rtc chip to determine > > that the oscillator was stopped. After a reboot all is well, because > > the rtc oscillator gets started when the time is written to the chip, > > and it keeps running through a reboot and only stops on a power cycle. > > Agreed, but there is a story behind. > The board had a design flaw in that it drained the battery over the > pullups into the Pi when the Pi was powered down. > I fixed that circuit and did power down tests as well. > Don't know if the previous boot was after power down, but it is > unlikely that the battery is dead again and if it was a power down then > it was a rather short one. > It is not a test system, I run it 24/7 as a local ntp server since about > only 1-2 months. Well - lets reveal another point. I have removed the pull ups completely, in the assumption that the Pi itself has propper pull ups for at least short wiring. It did work, so I left it that way. So it could indeed be transfer errors by inadequate pull ups causing it. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Mon Mar 25 17:17:26 2019 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 D4BF91546B17 for ; Mon, 25 Mar 2019 17:17:25 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 10DB376676; Mon, 25 Mar 2019 17:17:24 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 85C70211098; Mon, 25 Mar 2019 13:16:53 -0400 (EDT) Received: from [192.168.10.14] (D4.Denninger.Net [192.168.10.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 1302BD0D6D; Mon, 25 Mar 2019 12:16:53 -0500 (CDT) Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] To: Ian Lepore , ticso@cicely.de Cc: "freebsd-arm@freebsd.org" References: <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> <20190319161423.GH57400@cicely7.cicely.de> <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> <40f57de2-2b25-3981-a416-b9958cc97636@denninger.net> <669892ac3fc37b0843a156c0ab102316829103fd.camel@freebsd.org> <663f2566-b035-7011-70eb-4163b41e6e55@denninger.net> <20190325164827.GL57400@cicely7.cicely.de> <3db9cf8a-68ee-e339-67bf-760ee51464fd@denninger.net> From: Karl Denninger Openpgp: preference=signencrypt Autocrypt: addr=karl@denninger.net; prefer-encrypt=mutual; keydata= mQINBFIX1zsBEADRcJfsQUl9oFeoMfLPJ1kql+3sIaYx0MfJAUhV9LnbWxr0fsWCskM1O4cV tHm5dqPkuPM4Ztc0jLotD1i9ubWvCHOlkLGxFOL+pFbjA+XZ7VKsC/xWmhMwJ3cM8HavK2OV SzEWQ/AEYtMi04IzGSwsxh/5/5R0mPHrsIomV5SbuiI0vjLuDj7fo6146AABI1ULzge4hBYW i/SHrqUrLORmUNBs6bxek79/B0Dzk5cIktD3LOfbT9EAa5J/osVkstMBhToJgQttaMIGv8SG CzpR/HwEokE+7DP+k2mLHnLj6H3kfugOF9pJH8Za4yFmw//s9cPXV8WwtZ2SKfVzn1unpKqf wmJ1PwJoom/d4fGvQDkgkGKRa6RGC6tPmXnqnx+YX4iCOdFfbP8L9rmk2sewDDVzHDU3I3ZZ 8hFIjMYM/QXXYszRatK0LCV0QPZuF7LCf4uQVKw1/oyJInsnH7+6a3c0h21x+CmSja9QJ+y0 yzgEN/nM89d6YTakfR+1xkYgodVmMy/bS8kmXbUUZG/CyeqCqc95RUySjKT2ECrf9GhhoQkl +D8n2MsrAUSMGB4GQSN+TIq9OBTpNuvATGSRuF9wnQcs1iSry+JNCpfRTyWp83uCNApe6oHU EET4Et6KDO3AvjvBMAX0TInTRGW2SQlJMuFKpc7Dg7tHK8zzqQARAQABtCNLYXJsIERlbm5p bmdlciA8a2FybEBkZW5uaW5nZXIubmV0PokCPAQTAQIAJgUCUhfXOwIbIwUJCWYBgAYLCQgH AwIEFQIIAwQWAgMBAh4BAheAAAoJEG6/sivc5s0PLxQP/i6x/QFx9G4Cw7C+LthhLXIm7NSH AtNbz2UjySEx2qkoQQjtsK6mcpEEaky4ky6t8gz0/SifIfJmSmyAx0UhUQ0WBv1vAXwtNrQQ jJd9Bj6l4c2083WaXyHPjt2u2Na6YFowyb4SaQb83hu/Zs25vkPQYJVVE0JX409MFVPUa6E3 zFbd1OTr3T4yNUy4gNeQZfzDqDS8slbIks2sXeoJrZ6qqXVI0ionoivOlaN4T6Q0UYyXtigj dQvvhMt0aNowKFjRqrmSDRpdz+o6yg7Mp7qEZ1V6EZk8KqQTH6htpCTQ8i79ttK4LG6bstSF Re6Fwq52nbrcANrcdmtZXqjo+SGbUqJ8b1ggrxAsJ5MEhRh2peKrCgI/TjQo+ZxfnqEoR4AI 46Cyiz+/lcVvlvmf2iPifS3EEdaH3Itfwt7MxFm6mQORYs6skHDw3tOYB2/AdCW6eRVYs2hB RMAG4uwApZfZDKgRoE95PJmQjeTBiGmRPcsQZtNESe7I7EjHtCDLwtJqvD4HkDDQwpzreT6W XkyIJ7ns7zDfA1E+AQhFR6rsTFGgQZRZKsVeov3SbhYKkCnVDCvb/PKQCAGkSZM9SvYG5Yax 8CMry3AefKktf9fqBFg8pWqtVxDwJr56dhi0GHXRu3jVI995rMGo1fLUG5fSxiZ8L5sAtokh 9WFmQpyl Message-ID: Date: Mon, 25 Mar 2019 12:16:52 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040803080506000701040205" X-Rspamd-Queue-Id: 10DB376676 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.35 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: px.denninger.net]; NEURAL_HAM_SHORT(-0.83)[-0.833,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-2.31)[ip: (-9.88), ipnet: 104.236.64.0/18(-3.62), asn: 14061(2.02), country: US(-0.07)]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:+]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[197.57.1.68.zen.spamhaus.org : 127.0.0.11]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; DMARC_NA(0.00)[denninger.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 17:17:26 -0000 This is a cryptographically signed message in MIME format. --------------ms040803080506000701040205 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/25/2019 12:05, Ian Lepore wrote: > On Mon, 2019-03-25 at 11:58 -0500, Karl Denninger wrote: >> On 3/25/2019 11:48, Bernd Walter wrote: >>> On Mon, Mar 25, 2019 at 11:33:32AM -0500, Karl Denninger wrote: >>>>> What do you mean by an insane rate? It's normal for the usb >>>>> controller >>>>> to be showing around thousands of int/sec. Despite what seems >>>>> like a >>>>> high rate, even on an on rpi-b it uses under 2% cpu to service >>>>> that. >>>>> >>>>> root@rpi:~ # vmstat -i >>>>> interrupt total rate >>>>> intc0,2: vchiq0 2 0 >>>>> intc0,11: systimer0 10103206 1110 >>>>> intc0,17:-x_dwcotg0 218596055 24007 >>>>> intc0,28: bcm_dma0 834 0 >>>>> intc0,61: iichb0 5778 1 >>>>> intc0,65: uart0 1817 0 >>>>> intc0,70:-dhci_bcm0 172 0 >>>>> Total 228707864 25118 >>>>> >>>>> -- Ian >>>> The story gets more odd. >>>> >>>> The same *physical* unit that I saw this on last night with no >>>> I2c >>>> device connected I restarted this morning -- changing NOTHING -- >>>> and it >>>> disappeared. >>>> >>>> But -- on another unit it's still there (I haven't shut down, >>>> pulled >>>> power and restarted that one.) >>>> >>>> vmstat -i on both doesn't show anything all that odd: >>>> misbehaving that's not there, and neither are the missed >>>> interrupt >>>> complaints. >>>> >>>> But again, last night the one that this morning is NOT >>>> misbehaving WAS, >>>> and was showing the exact same thing. >>>> >>>> So this looks like something that is not being initialized >>>> property at >>>> boot time, and sometimes however it comes up causes trouble, and >>>> other >>>> times it does not -- which is likely to make it a "lot" of fun to >>>> find. >>> By causing trouble - do you mean it doesn't work? >>> I noticed that my system has this message: >>> nxprtc0: RTC clock not running >>> Warning: bad time from time-of-day clock, system time will not be >>> set accurately >>> This shouldn't happen, but I wonder if the iic communication works >>> at all. >>> I likely wouldn't notice if the rtc failed. >>> Maybe there was an initial problem at start as you said. >>> Will reboot it and see what happens. >>> After a reboot the message about the rtc is gone. >>> Have to wait at least a day to see if the Spurious are gone too. >> In both cases on my boxes everything is working, but that's not >> unexpected because of the way my code works (it dynamically detects a >> change in configuration in that if it tries to open the I2c bus when >> there's a configuration file for devices on it, and it fails, it will >> try again in a few seconds -- and if you remove the config then it >> will >> shut down the I/O path in a short while and stop.) >> >> On the units that exhibit the problem the load average is 1.0 + >> whatever >> is real *and* the crazy interrupt rate is present. On the ones that >> are >> not neither is the case; the native and real load average is present >> and >> the interrupt rate is normal. >> >> In the case of the unit that the problem showed up on and then >> disappeared, however, while there's an I2c config defined there's no >> device connected to it on my bench. >> >> But I suspect this is something banging the interrupts on the CPU >> that >> is not attached to anything in the code, and the reason I suspect >> that >> is that on a given boot it either happens or not, and if it does then >> nothing I can do will make it stop -- and likewise, nothing I can do >> will make it start if it doesn't on boot. That implies that whatever >> it >> is it's not code-specific nor .ko-loaded specific either, in that if >> it >> was related specifically to an I2c device being talked to actively >> then >> when I killed the code that was using I2c or booted without the >> device >> connected (or never started the code that attempted to probe the bus >> and >> attach to the device in question) it wouldn't do it at all -- but >> that's >> not true. >> >> The one that stopped doing it I then attached both an I2c device that >> it >> was looking for and also connected a "modem-style" device (which >> caused >> umodem.ko to autoload, as expected) and it came up as well, without a >> problem -- and without triggering the mad interrupt storm. >> > Is the interrupt rate consistent from second to second? Running > 'vmstat 1' for a while might be useful to see that. That many > interrupts almost sounds like a line is floating, but if that were the > case I'd expect a widely varying number of int/sec. > > If you build custom kernels, it might be helpful to apply r345475 > locally... it will display partial device names instead of just '+' > when the name doesn't fit in the vmstat output. > > -- Ian No, but it's in the same general range -- around 500k although it does flop around some, and occasionally by a lot (e.g. if I sit and watch it it'll occasionally put up VERY different numbers -- e.g. a ~730k number, then it goes back, etc.) I don't generally build custom kernels on these but I CAN put this into the STABLE tree I'm building that from since I keep a separate one for Crochet builds on these boxes.=C2=A0 Where do I find that specific delta?= =C2=A0 (I usually just svn things and I don't want to roll it all the way back to there, right -- or do I?) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms040803080506000701040205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwMzI1MTcxNjUy WjBPBgkqhkiG9w0BCQQxQgRAEHEqnGW5pTjgFQPLKjBVmPXPYvMe2a31Io4cBmpYYYMKPDQ5 kyt9PLkDokednwJRviCZ65wxERn6D/YwHdN/9DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgB65K1rCV3MtlnrjuU392TN/4nuCHV9QrJy/2EfLxQzUH+kfSAXkh3EeXb8PccdCEi6 XuHJbMNAmmBvMdgGeWrNl4E3RH1BcY09+ZYojNeYLa/RNLEMiHukerYePW1YTaoukEugvPHf 47coAsajM3k8UtVlsCZz13ua6Bxhjb534E8ORrUR1pz+G7hP/CC+xVn9CydKHe48ntdii1Vs hPsCJNTx7kOwQvl3/XROPuk28uB7tThmKct0rTfOChcqJVKisD8GHIB8mqQwOzVIyzheE7Ak 6UaKIq17TEru2f3zS9ZS8IxK6Cp2HnoUCfGIG6bl2se87HuKumTyhF8GQioLkdU3poJZTHCJ LdcuSP9p8mT6ljAerNcmmpj6aZ5RIEbiu8ezc/T6KbjyCdJ+7yWGbJU8TyQSJ7Eky+wcldi6 ure0EU4hjKIDcQ6Q0MpQx/ALp7RYBxHnGxNuUYnbitrEgGS1V5BPEzjleb9aiKyD13Reefzo 3DMlEJOC3HA0LpWHV5hcfaota9yOygko8QdxlrK6J73J8IL9YUusjHEsPIqOpb7s7FE8Lu4T u5S1bYNTTXNB4QzkjKj3YdYNy8FxeDvWVWJxYo9fRi2G8LSpDW9JA9oaa0UtT7GoVzXdi8Cc /KYGKpu3q0DxydaMc+U2gzrkvJT9feRWcOze1RwxtwAAAAAAAA== --------------ms040803080506000701040205-- From owner-freebsd-arm@freebsd.org Mon Mar 25 17:19:11 2019 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 A60E21546BF9 for ; Mon, 25 Mar 2019 17:19:10 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 14B527672C; Mon, 25 Mar 2019 17:19:10 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id CCB61211098; Mon, 25 Mar 2019 13:18:38 -0400 (EDT) Received: from [192.168.10.14] (D4.Denninger.Net [192.168.10.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 6F5F8D0D8B; Mon, 25 Mar 2019 12:18:38 -0500 (CDT) Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] To: ticso@cicely.de, Ian Lepore Cc: "freebsd-arm@freebsd.org" References: <20190319161423.GH57400@cicely7.cicely.de> <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> <40f57de2-2b25-3981-a416-b9958cc97636@denninger.net> <669892ac3fc37b0843a156c0ab102316829103fd.camel@freebsd.org> <663f2566-b035-7011-70eb-4163b41e6e55@denninger.net> <20190325164827.GL57400@cicely7.cicely.de> <20190325170534.GM57400@cicely7.cicely.de> <20190325170948.GN57400@cicely7.cicely.de> From: Karl Denninger Openpgp: preference=signencrypt Autocrypt: addr=karl@denninger.net; prefer-encrypt=mutual; keydata= mQINBFIX1zsBEADRcJfsQUl9oFeoMfLPJ1kql+3sIaYx0MfJAUhV9LnbWxr0fsWCskM1O4cV tHm5dqPkuPM4Ztc0jLotD1i9ubWvCHOlkLGxFOL+pFbjA+XZ7VKsC/xWmhMwJ3cM8HavK2OV SzEWQ/AEYtMi04IzGSwsxh/5/5R0mPHrsIomV5SbuiI0vjLuDj7fo6146AABI1ULzge4hBYW i/SHrqUrLORmUNBs6bxek79/B0Dzk5cIktD3LOfbT9EAa5J/osVkstMBhToJgQttaMIGv8SG CzpR/HwEokE+7DP+k2mLHnLj6H3kfugOF9pJH8Za4yFmw//s9cPXV8WwtZ2SKfVzn1unpKqf wmJ1PwJoom/d4fGvQDkgkGKRa6RGC6tPmXnqnx+YX4iCOdFfbP8L9rmk2sewDDVzHDU3I3ZZ 8hFIjMYM/QXXYszRatK0LCV0QPZuF7LCf4uQVKw1/oyJInsnH7+6a3c0h21x+CmSja9QJ+y0 yzgEN/nM89d6YTakfR+1xkYgodVmMy/bS8kmXbUUZG/CyeqCqc95RUySjKT2ECrf9GhhoQkl +D8n2MsrAUSMGB4GQSN+TIq9OBTpNuvATGSRuF9wnQcs1iSry+JNCpfRTyWp83uCNApe6oHU EET4Et6KDO3AvjvBMAX0TInTRGW2SQlJMuFKpc7Dg7tHK8zzqQARAQABtCNLYXJsIERlbm5p bmdlciA8a2FybEBkZW5uaW5nZXIubmV0PokCPAQTAQIAJgUCUhfXOwIbIwUJCWYBgAYLCQgH AwIEFQIIAwQWAgMBAh4BAheAAAoJEG6/sivc5s0PLxQP/i6x/QFx9G4Cw7C+LthhLXIm7NSH AtNbz2UjySEx2qkoQQjtsK6mcpEEaky4ky6t8gz0/SifIfJmSmyAx0UhUQ0WBv1vAXwtNrQQ jJd9Bj6l4c2083WaXyHPjt2u2Na6YFowyb4SaQb83hu/Zs25vkPQYJVVE0JX409MFVPUa6E3 zFbd1OTr3T4yNUy4gNeQZfzDqDS8slbIks2sXeoJrZ6qqXVI0ionoivOlaN4T6Q0UYyXtigj dQvvhMt0aNowKFjRqrmSDRpdz+o6yg7Mp7qEZ1V6EZk8KqQTH6htpCTQ8i79ttK4LG6bstSF Re6Fwq52nbrcANrcdmtZXqjo+SGbUqJ8b1ggrxAsJ5MEhRh2peKrCgI/TjQo+ZxfnqEoR4AI 46Cyiz+/lcVvlvmf2iPifS3EEdaH3Itfwt7MxFm6mQORYs6skHDw3tOYB2/AdCW6eRVYs2hB RMAG4uwApZfZDKgRoE95PJmQjeTBiGmRPcsQZtNESe7I7EjHtCDLwtJqvD4HkDDQwpzreT6W XkyIJ7ns7zDfA1E+AQhFR6rsTFGgQZRZKsVeov3SbhYKkCnVDCvb/PKQCAGkSZM9SvYG5Yax 8CMry3AefKktf9fqBFg8pWqtVxDwJr56dhi0GHXRu3jVI995rMGo1fLUG5fSxiZ8L5sAtokh 9WFmQpyl Message-ID: Date: Mon, 25 Mar 2019 12:18:37 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <20190325170948.GN57400@cicely7.cicely.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060601070303020901060003" X-Rspamd-Queue-Id: 14B527672C X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.36 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: px.denninger.net]; NEURAL_HAM_SHORT(-0.83)[-0.832,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-2.32)[ip: (-9.88), ipnet: 104.236.64.0/18(-3.65), asn: 14061(2.02), country: US(-0.07)]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:+]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[197.57.1.68.zen.spamhaus.org : 127.0.0.11]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; DMARC_NA(0.00)[denninger.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 17:19:11 -0000 This is a cryptographically signed message in MIME format. --------------ms060601070303020901060003 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/25/2019 12:09, Bernd Walter wrote: > On Mon, Mar 25, 2019 at 06:05:35PM +0100, Bernd Walter wrote: >> On Mon, Mar 25, 2019 at 10:52:26AM -0600, Ian Lepore wrote: >>> On Mon, 2019-03-25 at 17:48 +0100, Bernd Walter wrote: >>>> On Mon, Mar 25, 2019 at 11:33:32AM -0500, Karl Denninger wrote: >>>>>> What do you mean by an insane rate? It's normal for the usb >>>>>> controller >>>>>> to be showing around thousands of int/sec. Despite what seems >>>>>> like a >>>>>> high rate, even on an on rpi-b it uses under 2% cpu to service >>>>>> that. >>>>>> >>>>>> root@rpi:~ # vmstat -i >>>>>> interrupt total rate >>>>>> intc0,2: vchiq0 2 0 >>>>>> intc0,11: systimer0 10103206 1110 >>>>>> intc0,17:-x_dwcotg0 218596055 24007 >>>>>> intc0,28: bcm_dma0 834 0 >>>>>> intc0,61: iichb0 5778 1 >>>>>> intc0,65: uart0 1817 0 >>>>>> intc0,70:-dhci_bcm0 172 0 >>>>>> Total 228707864 25118 >>>>>> >>>>>> -- Ian >>>>> The story gets more odd. >>>>> >>>>> The same *physical* unit that I saw this on last night with no I2c >>>>> device connected I restarted this morning -- changing NOTHING -- >>>>> and it >>>>> disappeared. >>>>> >>>>> But -- on another unit it's still there (I haven't shut down, >>>>> pulled >>>>> power and restarted that one.) >>>>> >>>>> vmstat -i on both doesn't show anything all that odd: >>>>> misbehaving that's not there, and neither are the missed interrupt >>>>> complaints. >>>>> >>>>> But again, last night the one that this morning is NOT misbehaving >>>>> WAS, >>>>> and was showing the exact same thing. >>>>> >>>>> So this looks like something that is not being initialized property= >>>>> at >>>>> boot time, and sometimes however it comes up causes trouble, and >>>>> other >>>>> times it does not -- which is likely to make it a "lot" of fun to >>>>> find. >>>> By causing trouble - do you mean it doesn't work? >>>> I noticed that my system has this message: >>>> nxprtc0: RTC clock not running >>>> Warning: bad time from time-of-day clock, system time will not be se= t >>>> accurately >>>> This shouldn't happen, but I wonder if the iic communication works a= t >>>> all. >>>> I likely wouldn't notice if the rtc failed. >>>> Maybe there was an initial problem at start as you said. >>>> Will reboot it and see what happens. >>>> After a reboot the message about the rtc is gone. >>>> Have to wait at least a day to see if the Spurious are gone too. >>>> >>> That's not a symptom of i2c comms failure, it's a symptom of a dead r= tc >>> battery. The driver has to communicate with the rtc chip to determin= e >>> that the oscillator was stopped. After a reboot all is well, because= >>> the rtc oscillator gets started when the time is written to the chip,= >>> and it keeps running through a reboot and only stops on a power cycle= =2E >> Agreed, but there is a story behind. >> The board had a design flaw in that it drained the battery over the >> pullups into the Pi when the Pi was powered down. >> I fixed that circuit and did power down tests as well. >> Don't know if the previous boot was after power down, but it is >> unlikely that the battery is dead again and if it was a power down the= n >> it was a rather short one. >> It is not a test system, I run it 24/7 as a local ntp server since abo= ut >> only 1-2 months. > Well - lets reveal another point. > I have removed the pull ups completely, in the assumption that the Pi i= tself > has propper pull ups for at least short wiring. > It did work, so I left it that way. > So it could indeed be transfer errors by inadequate pull ups causing it= =2E Not in my case - the board that was doing it, I power-cycled it and it disappeared has NOTHING on any of the header/GPIO pins except for the three wires connected to the USB/Serial interface for the console. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060601070303020901060003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwMzI1MTcxODM3 WjBPBgkqhkiG9w0BCQQxQgRAvHVjXQvIdz+l6mtmV60Tf01aA0ggDhj83QjDFb3GzX+5rGkG zC3Gn4W16avjXgJJ0lOJCSoz/VIuUOyeMLbnlzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgCvmoLJaLdQpur5nq/Dju907Pk2hzviyeoWsMO7mQqcY4zJxUbCWDcdWYR2r1HRxM9r oLyDwhjcTeFJB6Ta8m1XXd1AMmNJqTfZKrIafvYhHhznCaQtUgZ9hRlUcheYRQ6QQjV/xCa2 mzTIVX4MnBs5XMIV6+5mM1ywMKNXuRVWeUPg1iL5Rh3HY+29QZTnzeL/Mn6ossWLTCQZsBoV SFn3fRr7OvhVhou4o3Xp8YK36JJ0V45yb0rAKXpxjnwIgw/l6PDvZvPxXMaBVt8lLDIZ141G mIb6duFIO1tqkTxThvLUkcXHuCHDqtIOxvjnGE4pNhdWaDL7ZKz0h9OvUsYnUyA8jLWWb3GV tC0Neuv8rrlfgbYn4cBlD062MEqiLSbEN1q8TSJF/AocuvsWl/qqpz9VDxfeQjpV8xelDzSs Tjfv4We0u98SUloiwGhsInTgxJ8uYpj6isLJ3EA57YAHNLSw5L2na9w1Q9tTVvGl9oC1TJnr Q6dQpYFfqmfjCnOY7JF+yZHvki6Y0TEWAeTb91bA4KyccbPxwCgMIU4eOqNoyp2UT9I2pR4/ XQzqwB0kAMR6z8WFIx49V/0JTQeqxhSalLa6k8U2Myh3rPPWlJFlSnjw5mhRKbLA/ueD7Nf4 4DGBYlleo6VqKVFIXSAT+2xkhK8dyogSanMVQvhN7QAAAAAAAA== --------------ms060601070303020901060003-- From owner-freebsd-arm@freebsd.org Mon Mar 25 17:38:04 2019 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 418341547479 for ; Mon, 25 Mar 2019 17:38:04 +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 77D737733E for ; Mon, 25 Mar 2019 17:38:03 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1553535476; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=DKuGspwKwisZHcphj5D6Plekr1RFCYnfxr7WVp1on98dz45F7a5E735VAdALbx08B45aCE6BQevhh zgXSt3sLwGgt/yvvMy0YekqlPchvJkj5MgJBHUkaGH2duqXzoB48Y+PFLgSF56YRbueL+QtA9XEXw/ aEuE24vkJRO1qntNrc4prRe4OJLDsfOio1DnkzdMqNIylzG4KOPuJyE9M64uiOeWi0gVqAg6gaLh3J msfeneRjW+sRQN+WJTJRy7Ai7r+Zrpg6rPRWvPrBDWYgOt4DQQNtddjMP9YypOphAnKlTM9h32RvDT jbIKsB6yxPEFQkgamd9xw2AxRE6bgZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=fkdTZdtTPFb9rqVPzN2C9VGRMUswW3w6bteppNgNwtQ=; b=DMO20DbD0O09arLeEpa0bEgN/Ssq0uDUIQhpX/yW7wTAvyCWIyNPXZhp475bPtVEcytPe8544cHD6 YhR2nHS0hFHaeff36Gw+qk9+EHEeRH7hU+0StoqvIuq/TjtYxHqH9uJa1sPFNs2dV7RN/5QFAERbX6 /ojhNiKnX6X4vqV7RQKEiXgZrvB5t7AkA/jQk3C9vKmuwbLLfE6WYhSYhge5LnwOMrwsVgqEEtqjnn zME7XWBPytbYRQu/ELGjfeHJw4kQpi8TQ7gRaaCBBISNVFCniwsT9h/xRTasZ4tWSM8+qoKwpvcx83 trpC3yMfIuFLtHrfA3YGHoiq36ymxzg== ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=fkdTZdtTPFb9rqVPzN2C9VGRMUswW3w6bteppNgNwtQ=; b=iPELcLYgb3oqs10fBJtZltHBeRWYN24TuKZPBpnvbnp6qygbb5aEczJSbNIdwDT2+AM3i2OJea0RF mDPCr5CSNW3PsI5aDBGEiHKF2DCt0oqe6m2slyPHa4JeCKUMFYeil67WROpAIMJYa0mxV0i0FFm0yF YTBIoYHa/TRJJhwLe3vPqIB/EgVUzNWsuCHgah85QsSiUHt54TfA+npU7oj0DjPncWwysTnSDslCM1 QELEePK+LFciPNwURrJY8sliyEE+BgyKB6MxDVYYwdiJGxMAXtYSM2Ichk/JUHjQy5V5Gr6YA0FKlh wuaBKQ8ShNqi1veROgYz5yZPNMvofOg== X-MHO-RoutePath: aGlwcGll X-MHO-User: b6440e4a-4f24-11e9-803b-31925da7267c 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.eu.mailhop.org (Halon) with ESMTPSA id b6440e4a-4f24-11e9-803b-31925da7267c; Mon, 25 Mar 2019 17:37:52 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x2PHbok3083923; Mon, 25 Mar 2019 11:37:50 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <30c8e58c15aec809522b5aa563755d66fea0f4ac.camel@freebsd.org> Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] From: Ian Lepore To: Karl Denninger , ticso@cicely.de Cc: "freebsd-arm@freebsd.org" Date: Mon, 25 Mar 2019 11:37:50 -0600 In-Reply-To: References: <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> <20190319161423.GH57400@cicely7.cicely.de> <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> <40f57de2-2b25-3981-a416-b9958cc97636@denninger.net> <669892ac3fc37b0843a156c0ab102316829103fd.camel@freebsd.org> <663f2566-b035-7011-70eb-4163b41e6e55@denninger.net> <20190325164827.GL57400@cicely7.cicely.de> <3db9cf8a-68ee-e339-67bf-760ee51464fd@denninger.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 77D737733E X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; ASN(0.00)[asn:16509, ipnet:52.58.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 17:38:04 -0000 On Mon, 2019-03-25 at 12:16 -0500, Karl Denninger wrote: > On 3/25/2019 12:05, Ian Lepore wrote: > > On Mon, 2019-03-25 at 11:58 -0500, Karl Denninger wrote: > > > [...] > > > > Is the interrupt rate consistent from second to second? Running > > 'vmstat 1' for a while might be useful to see that. That many > > interrupts almost sounds like a line is floating, but if that were the > > case I'd expect a widely varying number of int/sec. > > > > If you build custom kernels, it might be helpful to apply r345475 > > locally... it will display partial device names instead of just '+' > > when the name doesn't fit in the vmstat output. > > > > -- Ian > > No, but it's in the same general range -- around 500k although it does > flop around some, and occasionally by a lot (e.g. if I sit and watch it > it'll occasionally put up VERY different numbers -- e.g. a ~730k number, > then it goes back, etc.) > > I don't generally build custom kernels on these but I CAN put this into > the STABLE tree I'm building that from since I keep a separate one for > Crochet builds on these boxes. Where do I find that specific delta? (I > usually just svn things and I don't want to roll it all the way back to > there, right -- or do I?) > Apply this patch... https://svnweb.freebsd.org/base/head/sys/kern/kern_intr.c?view=patch&r1=345475&r2=345474&pathrev=345475 -- Ian From owner-freebsd-arm@freebsd.org Mon Mar 25 19:26:16 2019 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 1989D154AD2A for ; Mon, 25 Mar 2019 19:26:16 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 D2D2D84293; Mon, 25 Mar 2019 19:26:14 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id A4070211098; Mon, 25 Mar 2019 15:25:43 -0400 (EDT) Received: from [192.168.10.14] (D4.Denninger.Net [192.168.10.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id F16AFC83D0; Mon, 25 Mar 2019 14:25:42 -0500 (CDT) Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] To: Ian Lepore , ticso@cicely.de Cc: "freebsd-arm@freebsd.org" References: <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> <20190319161423.GH57400@cicely7.cicely.de> <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> <40f57de2-2b25-3981-a416-b9958cc97636@denninger.net> <669892ac3fc37b0843a156c0ab102316829103fd.camel@freebsd.org> <663f2566-b035-7011-70eb-4163b41e6e55@denninger.net> <20190325164827.GL57400@cicely7.cicely.de> <3db9cf8a-68ee-e339-67bf-760ee51464fd@denninger.net> <30c8e58c15aec809522b5aa563755d66fea0f4ac.camel@freebsd.org> From: Karl Denninger Openpgp: preference=signencrypt Autocrypt: addr=karl@denninger.net; prefer-encrypt=mutual; keydata= mQINBFIX1zsBEADRcJfsQUl9oFeoMfLPJ1kql+3sIaYx0MfJAUhV9LnbWxr0fsWCskM1O4cV tHm5dqPkuPM4Ztc0jLotD1i9ubWvCHOlkLGxFOL+pFbjA+XZ7VKsC/xWmhMwJ3cM8HavK2OV SzEWQ/AEYtMi04IzGSwsxh/5/5R0mPHrsIomV5SbuiI0vjLuDj7fo6146AABI1ULzge4hBYW i/SHrqUrLORmUNBs6bxek79/B0Dzk5cIktD3LOfbT9EAa5J/osVkstMBhToJgQttaMIGv8SG CzpR/HwEokE+7DP+k2mLHnLj6H3kfugOF9pJH8Za4yFmw//s9cPXV8WwtZ2SKfVzn1unpKqf wmJ1PwJoom/d4fGvQDkgkGKRa6RGC6tPmXnqnx+YX4iCOdFfbP8L9rmk2sewDDVzHDU3I3ZZ 8hFIjMYM/QXXYszRatK0LCV0QPZuF7LCf4uQVKw1/oyJInsnH7+6a3c0h21x+CmSja9QJ+y0 yzgEN/nM89d6YTakfR+1xkYgodVmMy/bS8kmXbUUZG/CyeqCqc95RUySjKT2ECrf9GhhoQkl +D8n2MsrAUSMGB4GQSN+TIq9OBTpNuvATGSRuF9wnQcs1iSry+JNCpfRTyWp83uCNApe6oHU EET4Et6KDO3AvjvBMAX0TInTRGW2SQlJMuFKpc7Dg7tHK8zzqQARAQABtCNLYXJsIERlbm5p bmdlciA8a2FybEBkZW5uaW5nZXIubmV0PokCPAQTAQIAJgUCUhfXOwIbIwUJCWYBgAYLCQgH AwIEFQIIAwQWAgMBAh4BAheAAAoJEG6/sivc5s0PLxQP/i6x/QFx9G4Cw7C+LthhLXIm7NSH AtNbz2UjySEx2qkoQQjtsK6mcpEEaky4ky6t8gz0/SifIfJmSmyAx0UhUQ0WBv1vAXwtNrQQ jJd9Bj6l4c2083WaXyHPjt2u2Na6YFowyb4SaQb83hu/Zs25vkPQYJVVE0JX409MFVPUa6E3 zFbd1OTr3T4yNUy4gNeQZfzDqDS8slbIks2sXeoJrZ6qqXVI0ionoivOlaN4T6Q0UYyXtigj dQvvhMt0aNowKFjRqrmSDRpdz+o6yg7Mp7qEZ1V6EZk8KqQTH6htpCTQ8i79ttK4LG6bstSF Re6Fwq52nbrcANrcdmtZXqjo+SGbUqJ8b1ggrxAsJ5MEhRh2peKrCgI/TjQo+ZxfnqEoR4AI 46Cyiz+/lcVvlvmf2iPifS3EEdaH3Itfwt7MxFm6mQORYs6skHDw3tOYB2/AdCW6eRVYs2hB RMAG4uwApZfZDKgRoE95PJmQjeTBiGmRPcsQZtNESe7I7EjHtCDLwtJqvD4HkDDQwpzreT6W XkyIJ7ns7zDfA1E+AQhFR6rsTFGgQZRZKsVeov3SbhYKkCnVDCvb/PKQCAGkSZM9SvYG5Yax 8CMry3AefKktf9fqBFg8pWqtVxDwJr56dhi0GHXRu3jVI995rMGo1fLUG5fSxiZ8L5sAtokh 9WFmQpyl Message-ID: Date: Mon, 25 Mar 2019 14:25:42 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <30c8e58c15aec809522b5aa563755d66fea0f4ac.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030108000606010303040705" X-Rspamd-Queue-Id: D2D2D84293 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.35 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: px.denninger.net]; MIME_BASE64_TEXT(0.10)[]; NEURAL_HAM_SHORT(-0.91)[-0.911,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-2.33)[ip: (-9.88), ipnet: 104.236.64.0/18(-3.70), asn: 14061(2.01), country: US(-0.07)]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:+]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[197.57.1.68.zen.spamhaus.org : 127.0.0.11]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; DMARC_NA(0.00)[denninger.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 19:26:16 -0000 This is a cryptographically signed message in MIME format. --------------ms030108000606010303040705 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 DQpPbiAzLzI1LzIwMTkgMTI6MzcsIElhbiBMZXBvcmUgd3JvdGU6DQo+IE9uIE1vbiwgMjAx OS0wMy0yNSBhdCAxMjoxNiAtMDUwMCwgS2FybCBEZW5uaW5nZXIgd3JvdGU6DQo+PiBPbiAz LzI1LzIwMTkgMTI6MDUsIElhbiBMZXBvcmUgd3JvdGU6DQo+Pj4gT24gTW9uLCAyMDE5LTAz LTI1IGF0IDExOjU4IC0wNTAwLCBLYXJsIERlbm5pbmdlciB3cm90ZToNCj4+Pj4gWy4uLl0N Cj4+PiBJcyB0aGUgaW50ZXJydXB0IHJhdGUgY29uc2lzdGVudCBmcm9tIHNlY29uZCB0byBz ZWNvbmQ/ICBSdW5uaW5nDQo+Pj4gJ3Ztc3RhdCAxJyBmb3IgYSB3aGlsZSBtaWdodCBiZSB1 c2VmdWwgdG8gc2VlIHRoYXQuICBUaGF0IG1hbnkNCj4+PiBpbnRlcnJ1cHRzIGFsbW9zdCBz b3VuZHMgbGlrZSBhIGxpbmUgaXMgZmxvYXRpbmcsIGJ1dCBpZiB0aGF0IHdlcmUgdGhlDQo+ Pj4gY2FzZSBJJ2QgZXhwZWN0IGEgd2lkZWx5IHZhcnlpbmcgbnVtYmVyIG9mIGludC9zZWMu DQo+Pj4NCj4+PiBJZiB5b3UgYnVpbGQgY3VzdG9tIGtlcm5lbHMsIGl0IG1pZ2h0IGJlIGhl bHBmdWwgdG8gYXBwbHkgcjM0NTQ3NQ0KPj4+IGxvY2FsbHkuLi4gaXQgd2lsbCBkaXNwbGF5 IHBhcnRpYWwgZGV2aWNlIG5hbWVzIGluc3RlYWQgb2YganVzdCAnKycNCj4+PiB3aGVuIHRo ZSBuYW1lIGRvZXNuJ3QgZml0IGluIHRoZSB2bXN0YXQgb3V0cHV0Lg0KPj4+DQo+Pj4gLS0g SWFuDQo+PiBObywgYnV0IGl0J3MgaW4gdGhlIHNhbWUgZ2VuZXJhbCByYW5nZSAtLSBhcm91 bmQgNTAwayBhbHRob3VnaCBpdCBkb2VzDQo+PiBmbG9wIGFyb3VuZCBzb21lLCBhbmQgb2Nj YXNpb25hbGx5IGJ5IGEgbG90IChlLmcuIGlmIEkgc2l0IGFuZCB3YXRjaCBpdA0KPj4gaXQn bGwgb2NjYXNpb25hbGx5IHB1dCB1cCBWRVJZIGRpZmZlcmVudCBudW1iZXJzIC0tIGUuZy4g YSB+NzMwayBudW1iZXIsDQo+PiB0aGVuIGl0IGdvZXMgYmFjaywgZXRjLikNCj4+DQo+PiBJ IGRvbid0IGdlbmVyYWxseSBidWlsZCBjdXN0b20ga2VybmVscyBvbiB0aGVzZSBidXQgSSBD QU4gcHV0IHRoaXMgaW50bw0KPj4gdGhlIFNUQUJMRSB0cmVlIEknbSBidWlsZGluZyB0aGF0 IGZyb20gc2luY2UgSSBrZWVwIGEgc2VwYXJhdGUgb25lIGZvcg0KPj4gQ3JvY2hldCBidWls ZHMgb24gdGhlc2UgYm94ZXMuICBXaGVyZSBkbyBJIGZpbmQgdGhhdCBzcGVjaWZpYyBkZWx0 YT8gIChJDQo+PiB1c3VhbGx5IGp1c3Qgc3ZuIHRoaW5ncyBhbmQgSSBkb24ndCB3YW50IHRv IHJvbGwgaXQgYWxsIHRoZSB3YXkgYmFjayB0bw0KPj4gdGhlcmUsIHJpZ2h0IC0tIG9yIGRv IEk/KQ0KPj4NCj4gQXBwbHkgdGhpcyBwYXRjaC4uLg0KPg0KPiBodHRwczovL3N2bndlYi5m cmVlYnNkLm9yZy9iYXNlL2hlYWQvc3lzL2tlcm4va2Vybl9pbnRyLmM/dmlldz1wYXRjaCZy MT0zNDU0NzUmcjI9MzQ1NDc0JnBhdGhyZXY9MzQ1NDc1DQo+DQo+IC0tIElhbg0KDQpIZXJl J3Mgd2hlcmUgaXQncyBjb21pbmcgZnJvbToNCg0Kcm9vdEBycGkyOn4gIyB2bXN0YXQgLWkN CmludGVycnVwdMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdG90YWzCoMKg wqDCoMKgwqAgcmF0ZQ0KbG9jYWxfaW50YzAsMTotbWVyMMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDgwOTQ0 wqDCoMKgwqDCoMKgIDEzNjENCmxvY2FsX2ludGMwLDM6LW1lcjDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAzMjIxMDI4 N8KgwqDCoMKgIDU0MTYwNA0KbG9jYWxfaW50YzAsODotbnRjMMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA4ODgz NDHCoMKgwqDCoMKgIDE0OTM3DQpsb2NhbF9pbnRjMCw5OiBwbXUwwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCAywqDCoMKgwqDCoMKgwqDCoMKgIDANCmludGMwLDE6IG1ib3gwwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIDQwwqDCoMKgwqDCoMKgwqDCoMKgIDENCmludGMwLDI6 IHZjaGlxMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAywqDCoMKgwqDCoMKgwqDC oMKgIDANCmludGMwLDE3Oi14X2R3Y290ZzDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDEyNDIyNznCoMKgwqDCoMKg IDIwODg4DQppbnRjMCwyODogYmNtX2RtYTDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDc0Njg2wqDCoMKg wqDCoMKgIDEyNTYNCmludGMwLDYxOiBpaWNoYjDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIDHCoMKgwqDCoMKgwqDCoMKgwqAgMA0KaW50YzAsNjU6IHVhcnQwwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIDE4NTbCoMKgwqDCoMKgwqDCoMKgIDMxDQppbnRjMCw3MDotZGhjaV9i Y20wwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCA4OTUywqDCoMKgwqDCoMKgwqAgMTUxDQpjcHUwOnJlbmRl enZvdXPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDEzwqDCoMKgwqDCoMKgwqDCoMKg IDANCmNwdTE6cmVuZGV6dm91c8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMTTCoMKg wqDCoMKgwqDCoMKgwqAgMA0KY3B1MjpyZW5kZXp2b3VzwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCAxNcKgwqDCoMKgwqDCoMKgwqDCoCAwDQpjcHUzOnJlbmRlenZvdXPCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIDE4wqDCoMKgwqDCoMKgwqDCoMKgIDANCmNwdTI6YXN0 wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMcKgwqDCoMKg wqDCoMKgwqDCoCAwDQpjcHUwOnByZWVtcHTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgMzE2N8KgwqDCoMKgwqDCoMKgwqAgNTMNCmNwdTE6cHJlZW1wdMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgMTMwNjLCoMKgwqDCoMKgwqDCoCAyMjANCmNwdTI6cHJlZW1wdMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMTExMzPCoMKgwqDCoMKgwqDCoCAxODcNCmNw dTA6aGFyZGNsb2NrwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMsKgwqDCoMKg wqDCoMKgwqDCoCAwDQpUb3RhbMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCAzNDUzNDgxNcKgwqDCoMKgIDU4MDY5MA0KDQpVaCwgeWVhaC7CoCBDb2xkIGJvb3QsIE5P IEkyYyBjb25uZWN0ZWQuDQoNCkZyZWVCU0QgMTIuMC1TVEFCTEUgIzAgcjM0NTQ5ME06IE1v biBNYXIgMjUgMTQ6MDU6NDcgQ0RUIDIwMTnCoMKgwqDCoA0Ka2FybEBOZXdGUy5kZW5uaW5n ZXIubmV0Oi93b3JrL0Nyb2NoZXQtd29yay1BUk0zMi9vYmovd29yay9Dcm9zc0J1aWxkLTEy U1RBQkxFL3NyYy9hcm0uYXJtdjcvc3lzL0dFTkVSSUMNCg0KKHBsdXMgdGhlIHBhdGNoIG9m IGNvdXJzZSkNCg0KTm8gLmtvcyBsb2FkZWQgZWl0aGVyDQoNCnJvb3RAcnBpMjp+ICMga2xk c3RhdA0KSWQgUmVmcyBBZGRyZXNzwqDCoMKgwqDCoMKgwqAgU2l6ZSBOYW1lDQrCoDHCoMKg wqAgMSAweGMwMDAwMDAwwqDCoCBjYTUzZTQga2VybmVsDQoNCkFuZCB0aGUgbG9hZCBhdmVy YWdlIG9mIDEuMCArIHJlYWwgaXMgdGhlcmU6DQoNCnJvb3RAcnBpMjp+ICMgdXB0aW1lDQrC oDc6MTVQTcKgIHVwIDQgbWlucywgMSB1c2VyLCBsb2FkIGF2ZXJhZ2VzOiAxLjA0LCAwLjc1 LCAwLjM1DQoNCi0tIA0KS2FybCBEZW5uaW5nZXINCmthcmxAZGVubmluZ2VyLm5ldCA8bWFp bHRvOmthcmxAZGVubmluZ2VyLm5ldD4NCi9UaGUgTWFya2V0IFRpY2tlci8NCi9bUy9NSU1F IGVuY3J5cHRlZCBlbWFpbCBwcmVmZXJyZWRdLw0K --------------ms030108000606010303040705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwMzI1MTkyNTQy WjBPBgkqhkiG9w0BCQQxQgRAAE2XgU6AJsCRzUl3MR4DHkl1ruv6+MMCIzIZIA29GRMoAkja qhYI3t71MMaMbjGiAml4tk0WmZmmr5XkOdbxqTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgCfwUmmQRNIkeYjl0gK0N9PSfopYHDKgsuncG0+UjkNNvgCJfwdP5ll2XduVJ0A4MQb UH49w8qQvgUta0qu8AKssLasgBSxEXufIPLCF+ezdBPx1N0nlloIIND07YrPtehcjv3q7l0p UIb/wSAuOC+CwKqnCHVE9Flwf+4S8Zis8sYB2miyV7Xis0zccy0G2mN6uba3OxtJXynzKiSr fEbD4tWHiQzURhuBuyFvpfQv0xWNBhwxuc0UhR1vyYqVB2bnzKxLI4UeZg9GVtSvIskNfCgH W478dfd4E/EHymXr9OzV+OrZjc2V15CmQRGvayNEBrOM1h0mQovceEVeHbT6jv352d7EM0ma gyTBF+To66JgEJ+vayETSU7cuRsyVbrIuJxV8d85BSK/qu2K1Zc9/F85a5b/Y0YcKE9TQB3o oGUW6d8B1GkiiBXrrumrJSlukMkVE74/Cm6TgyPfnIUASSF+XbQhm+RcjdW6FAaDBzRdYnqe 4+hIS/68u9cV+CVro9Qam39v8ruhWiq/MV3teErIRkHXTjSQhwc8o3XJVxhlMVBGWW02TTkh gWFGH8uNR1aRO4IhnwgGT88lqSXl65SZ7iGPnnoAQ1MksiVTc7Kf0thEPVKcbr0F1W5EzZwV dHeSHaFG2lvg4lnSNB3FRexO2Y+dii/imHjbSVCFLQAAAAAAAA== --------------ms030108000606010303040705-- From owner-freebsd-arm@freebsd.org Mon Mar 25 20:00:34 2019 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 291F1154C1DF for ; Mon, 25 Mar 2019 20:00:34 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1.eu.mailhop.org (outbound1.eu.mailhop.org [52.28.251.132]) (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 5ED5C8551A for ; Mon, 25 Mar 2019 20:00:33 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1553544027; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=MzWwqbJG+hBSOnzsZ15brWFZ9uaVU+bi630aAIDgE/H+lxkdRfnENjygpQLJpCz8tQdlV+0aTKeG7 gO8xKg409jJqjcXMUwMmBOJrafS6dm10fNWB/mPc4mp4AOBr59uiSagGM/U+pYloLcAYZOaiO1Pv96 LGM5jkT9NRbjIQuJUb7Nc8zkSCE2WgqD0aR8ugb8nSTtYyuP/svWzSPHlYYRXwyryAIQ+Ts22oMSzg 9pOe4prgSchLQjoPCNv7ju9Y+AkSf7UDgB1HYzTUVcG1wi05GVG/FAkhzyQ1Uee/rl0WeDupQj3AFV GmFLDoDMqe4DBELkcekMAvTwf7RB0wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=e9wJc93cgj/ZSSuQ/mVzbKsamafrBiMu+eZPppgR9Ag=; b=QQxBQBa0Km231aS7RD1NiKyjBWvoO8F/Y/l46oB3PPrBv9X3p6ublpy16b91P3Z8gVyrxPduVgbg5 l7j/rYUCAGXnMODiTSEL0qq9+7J4o797zjL2LLIx9wGCxpkC7tLbjVF5wmIR6AMq+30IYwDwHjKhyU yvMKg0enIa/KjrYY7o9Rycv7bU6W2PY8AEanmQJ7VeUJJ851bEvt/K5O4RsKOey8p3D7hCwP+Oppze Zc1kM4SBxrac93SmcsxwcJLVfaKhfLIpRxQAapoLkLPB3EhQ3gEAEvNwxWKp/mSH6SzYSUqTVe0EZl bd9AKftQSeEAbZ+fHfjrFU2UV8p6FVw== ARC-Authentication-Results: i=1; outbound3.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=e9wJc93cgj/ZSSuQ/mVzbKsamafrBiMu+eZPppgR9Ag=; b=IkfgO9Y/JjCdqm79SNc6m+iB/+35XIkL20vCvCQs2N20oUhX8tMj7F1DdvVBszkAn0x/AORzZ8O4t QF4EJ0/IeZ1ytb3zJi0XE+0S1Smg3AxzZuvPn/JA+zvzz1J0bUX4ytWsIR3nEvT2z905hU/UmaHmcj 9N0xpB9iUrbC1Fk5U1znd35YvFGjdza+AeculZdAOKUAzqJi20npcN71Xo0KHseZPlS2F9A7rSqi+o OeV8AAyKfazKIMz2BQeOcc4S6BQQrs3Nk8tt45QuBhvPfRdrTas+UJ/u2JcL7ZuTLwVK7qoCv3NSwu O4VyD/KTn48LXg3g8YLJezTP65K/trQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: 9d4d38cf-4f38-11e9-908b-352056dbf2de 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 outbound3.eu.mailhop.org (Halon) with ESMTPSA id 9d4d38cf-4f38-11e9-908b-352056dbf2de; Mon, 25 Mar 2019 20:00:23 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x2PK0I9o084287; Mon, 25 Mar 2019 14:00:18 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <4f4e94ea0aeb325440960782aafe2dcb7a7b6ad3.camel@freebsd.org> Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] From: Ian Lepore To: Karl Denninger , ticso@cicely.de Cc: "freebsd-arm@freebsd.org" Date: Mon, 25 Mar 2019 14:00:18 -0600 In-Reply-To: References: <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> <20190319161423.GH57400@cicely7.cicely.de> <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> <40f57de2-2b25-3981-a416-b9958cc97636@denninger.net> <669892ac3fc37b0843a156c0ab102316829103fd.camel@freebsd.org> <663f2566-b035-7011-70eb-4163b41e6e55@denninger.net> <20190325164827.GL57400@cicely7.cicely.de> <3db9cf8a-68ee-e339-67bf-760ee51464fd@denninger.net> <30c8e58c15aec809522b5aa563755d66fea0f4ac.camel@freebsd.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 5ED5C8551A X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; ASN(0.00)[asn:16509, ipnet:52.28.0.0/16, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 20:00:34 -0000 On Mon, 2019-03-25 at 14:25 -0500, Karl Denninger wrote: > On 3/25/2019 12:37, Ian Lepore wrote: > > > > > > > [...] > > > > Apply this patch... > > > > https://svnweb.freebsd.org/base/head/sys/kern/kern_intr.c?view=patch&r1=345475&r2=345474&pathrev=345475 > > > > -- Ian > > Here's where it's coming from: > > root@rpi2:~ # vmstat -i > interrupt total rate > local_intc0,1:-mer0 80944 1361 > local_intc0,3:-mer0 32210287 541604 > local_intc0,8:-ntc0 888341 14937 > local_intc0,9: pmu0 2 0 > intc0,1: mbox0 40 1 > intc0,2: vchiq0 2 0 > intc0,17:-x_dwcotg0 1242279 20888 > intc0,28: bcm_dma0 74686 1256 > intc0,61: iichb0 1 0 > intc0,65: uart0 1856 31 > intc0,70:-dhci_bcm0 8952 151 > cpu0:rendezvous 13 0 > cpu1:rendezvous 14 0 > cpu2:rendezvous 15 0 > cpu3:rendezvous 18 0 > cpu2:ast 1 0 > cpu0:preempt 3167 53 > cpu1:preempt 13062 220 > cpu2:preempt 11133 187 > cpu0:hardclock 2 0 > Total 34534815 580690 > > We really need to change the name of the local_intc controller to something shorter. I'm going to venture a guess that -mer0 is 'timer0'. That leads to the question of whether the driver is broken somehow, or whether some callout is being scheduled for a crazy-high rate. -- Ian From owner-freebsd-arm@freebsd.org Wed Mar 27 19:26:28 2019 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 1557F1558677 for ; Wed, 27 Mar 2019 19:26:28 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C28058B010 for ; Wed, 27 Mar 2019 19:26:06 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.165] (helo=mjail2.freenet.de) by mout1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.90_1 #2) id 1h9EBW-000606-Sz for freebsd-arm@freebsd.org; Wed, 27 Mar 2019 20:26:02 +0100 Received: from [::1] (port=55338 helo=mjail2.freenet.de) by mjail2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1h9EBW-0005JQ-HN for freebsd-arm@freebsd.org; Wed, 27 Mar 2019 20:26:02 +0100 Received: from sub1.freenet.de ([195.4.92.120]:49718) by mjail2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1h9E8w-0003BR-An for freebsd-arm@freebsd.org; Wed, 27 Mar 2019 20:23:22 +0100 Received: from p4fd9f530.dip0.t-ipconnect.de ([79.217.245.48]:59443 helo=freebsd-t450.fritz.box) by sub1.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256) (port 587) (Exim 4.90_1 #2) id 1h9E8w-000889-Hz for freebsd-arm@freebsd.org; Wed, 27 Mar 2019 20:23:22 +0100 Date: Wed, 27 Mar 2019 20:23:20 +0100 From: Manuel =?iso-8859-15?Q?St=FChn?= To: freebsd-arm@freebsd.org Subject: efi-loader ignores dtb files? Message-ID: <20190327192320.GA64908@freebsd-t450.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.11.4 (2019-03-13) X-Originated-At: 79.217.245.48!59443 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 19:26:28 -0000 While trying to get FreeBSD 12.0 up and running on a NanoPI NEO2 (aarch64 Allwinner H5) I'm stumbling over issues with loader/loader.conf. FreeBSD starts fine, but it uses the devicetree-blob provided by uboot/EFI. I've tried to load the FreeBSD one by adding these lines to loader.conf: sun50i-h5-nanopi-neo2.dtb_load="YES" sun50i-h5-nanopi-neo2.dtb_type="dtb" and put the dtb file into /boot/dtb/sun50i-h5-nanopi-neo2.dtb, but this did not work at all. It got completely ignored by loader. The rest of the file was read and applied correctly (kernel-modules i'd added for testing purposes were loaded correctly). I tried to load it by hand like this: load -t dtb sun50i-h5-nanopi-neo2.dtb which worked, the dtb file was loaded and used. After consulting loader.conf(5) i found this way to load modules: dtbfile_load="YES" dtbfile_type="dtb" dtbfile_name="sun50i-h5-nanopi-neo2.dtb" and this finally triggered loader(8) to actually load the dtb. Unfortunatley the problem occurred again when i tried to add overlays. Those are, again, not recognized at all: /boot/loader.conf: fdt_overlays="sun50i-nanopi-neo2-codec.dtbo,sun50i-nanopi-neo2-sid.dtbo,sun50i-nanopi-neo2-ths.dtbo" Any ideas? BTW, is there a way to keep the u-boot logs printed before the FreeBSD-boot-menu gets drawn? The console gets cleared and erases some (valuable?) information. I was always to slow to stop the boot right after the last line of u-boot and the first of EFI. -- Manuel From owner-freebsd-arm@freebsd.org Wed Mar 27 19:35:43 2019 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 612BD1558D63 for ; Wed, 27 Mar 2019 19:35:43 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01C7B8BA06 for ; Wed, 27 Mar 2019 19:35:43 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id AAACC15868 for ; Wed, 27 Mar 2019 19:35:42 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f177.google.com with SMTP id p14so14508330ljg.5 for ; Wed, 27 Mar 2019 12:35:42 -0700 (PDT) X-Gm-Message-State: APjAAAUfTdwGc6GvVAvZ4omlOWgnSAYO0VnkGLsfOddc9QPhYp2j0grN IEBve6zUoB94dd2VJ4yxkAVFnlcOVWHGlx6wtVg= X-Google-Smtp-Source: APXvYqyd3cHEEGeoqvSS1niz2CmccQE31jWb1Hqkj3+gg7BIrhTvLyKrufBRcbSRrPXb8o7XdAk7jg3dMio6/zVziJk= X-Received: by 2002:a2e:8991:: with SMTP id c17mr3343601lji.83.1553715341093; Wed, 27 Mar 2019 12:35:41 -0700 (PDT) MIME-Version: 1.0 References: <20190327192320.GA64908@freebsd-t450.fritz.box> In-Reply-To: <20190327192320.GA64908@freebsd-t450.fritz.box> From: Kyle Evans Date: Wed, 27 Mar 2019 14:35:26 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: efi-loader ignores dtb files? To: =?UTF-8?Q?Manuel_St=C3=BChn?= Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 01C7B8BA06 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 19:35:43 -0000 On Wed, Mar 27, 2019 at 2:26 PM Manuel St=C3=BChn wrote: > > While trying to get FreeBSD 12.0 up and running on a NanoPI NEO2 > (aarch64 Allwinner H5) I'm stumbling over issues with > loader/loader.conf. FreeBSD starts fine, but it uses the > devicetree-blob provided by uboot/EFI. I've tried to load the FreeBSD > one by adding these lines to loader.conf: > > sun50i-h5-nanopi-neo2.dtb_load=3D"YES" > sun50i-h5-nanopi-neo2.dtb_type=3D"dtb" > > and put the dtb file into /boot/dtb/sun50i-h5-nanopi-neo2.dtb, but this > did not work at all. It got completely ignored by loader. The rest of > the file was read and applied correctly (kernel-modules i'd added for > testing purposes were loaded correctly). > > I tried to load it by hand like this: > > load -t dtb sun50i-h5-nanopi-neo2.dtb > > which worked, the dtb file was loaded and used. After consulting > loader.conf(5) i found this way to load modules: > > dtbfile_load=3D"YES" > dtbfile_type=3D"dtb" > dtbfile_name=3D"sun50i-h5-nanopi-neo2.dtb" > > and this finally triggered loader(8) to actually load the dtb. > Unfortunatley the problem occurred again when i tried to add overlays. > Those are, again, not recognized at all: > > /boot/loader.conf: > fdt_overlays=3D"sun50i-nanopi-neo2-codec.dtbo,sun50i-nanopi-neo2-sid.dtbo= ,sun50i-nanopi-neo2-ths.dtbo" > > Any ideas? Yes- for your first problem, loader doesn't recognize a period as a valid module name, so those directives would not have gotten recognized as modules to load. I'm not sure off-hand why fdt_overlays were not recognized. I would drop to loader prompt and double check that it actually ended up in the environment, but I don't see any reason off-hand that it wouldn't. It might be a good idea to drop to loader prompt and trigger overlay application. No output at all? > BTW, is there a way to keep the u-boot logs printed before the > FreeBSD-boot-menu gets drawn? The console gets cleared and erases some > (valuable?) information. I was always to slow to stop the boot right > after the last line of u-boot and the first of EFI. Any reason you need to keep the loader menu? Disabling it (beastie_disable=3D"YES") and lack of password prompts will stop the screen clearing in recent-ish versions of the lua scripts from head. Thanks, Kyle Evans From owner-freebsd-arm@freebsd.org Wed Mar 27 19:40:01 2019 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 4A1181558EFA for ; Wed, 27 Mar 2019 19:40:01 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 1731B8BC20 for ; Wed, 27 Mar 2019 19:39:59 +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 1h9EP0-000455-JV for freebsd-arm@freebsd.org; Wed, 27 Mar 2019 20:39:58 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Subject: Kernel panic (12.0-p3 RPI3B+ aarch64) References: <5c9bcead.139834.7da448bf@rpi3> Date: Wed, 27 Mar 2019 20:39:59 +0100 To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <5c9bcead.139834.7da448bf@rpi3> 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.2 X-Scan-Signature: 9b84bad32751a42de3aa9e7877f1ca86 X-Rspamd-Queue-Id: 1731B8BC20 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-3.06 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.992,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[klop.ws]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-0.69)[ip: (-2.39), ipnet: 195.190.28.0/24(-0.61), asn: 47172(-0.46), country: NL(0.01)]; MX_GOOD(-0.01)[cached: mx2.greenhost.nl]; NEURAL_HAM_SHORT(-0.57)[-0.571,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 19:40:01 -0000 Hi, I had a kernel panic last evening. My RPI3B+ had run out of mbuf clusters a couple of hours before. I logged in by serial cable and increased the sysctl kern.ipc.nmbclusters -> 30000 (the default is 19262) after which it looked like running ok. Any thoughts about this? Can I provide more information? Regards, Ronald. ------- Forwarded message ------- From: "FreeBSD Panic Reporting" To: root Cc: Subject: Kernel panic Date: Wed, 27 Mar 2019 20:27:41 +0100 A kernel panic has occurred on this system. You can assist in debugging this by allowing some information to be reported about this panic. The following information is contained in the encrypted panic report at the end of this email: > Dump header from device: /dev/gpt/ssddumpdev > Architecture: aarch64 > Architecture Version: 1 > Dump Length: 252329984 > Blocksize: 512 > Compression: none > Dumptime: Tue Mar 26 22:35:00 2019 > Hostname: rpi3 > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 12.0-RELEASE-p3 #10 r343874M: Thu Feb 7 > 20:19:54 CET 2019 > builder@rpi3:/data/src/obj-12/data/src/12/arm64.aarch64/sys/GENERIC-MMCCAM > Panic String: vm_fault failed: ffff00000067fab8 > Dump Parity: 1033498431 > Bounds: 6 > Dump Status: good > > Backtrace: > Reading symbols from /boot/kernel/kernel...(no debugging symbols > found)...done. > 0xffff0000003b6868 in sched_switch () > (kgdb) #0 0xffff0000003b6868 in sched_switch () > #1 0xffff000000393094 in mi_switch () > #2 0xffff0000003df134 in sleepq_wait () > #3 0xffff000000392cb4 in msleep_spin_sbt () > #4 0xffff0000003cfad0 in gtaskqueue_thread_loop () > #5 0xffff00000034a4f8 in fork_exit () > #6 > (kgdb) From owner-freebsd-arm@freebsd.org Wed Mar 27 20:22:07 2019 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 331291559F81 for ; Wed, 27 Mar 2019 20:22:07 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9456E8D709 for ; Wed, 27 Mar 2019 20:22:06 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.165] (helo=mjail2.freenet.de) by mout0.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.90_1 #2) id 1h9F3l-0005ME-Ju for freebsd-arm@freebsd.org; Wed, 27 Mar 2019 21:22:05 +0100 Received: from [::1] (port=46392 helo=mjail2.freenet.de) by mjail2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1h9F3l-0004EH-7q for freebsd-arm@freebsd.org; Wed, 27 Mar 2019 21:22:05 +0100 Received: from sub8.freenet.de ([195.4.92.127]:57350) by mjail2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1h9F1b-0000MH-Gy for freebsd-arm@freebsd.org; Wed, 27 Mar 2019 21:19:51 +0100 Received: from p4fd9f530.dip0.t-ipconnect.de ([79.217.245.48]:31151 helo=freebsd-t450.fritz.box) by sub8.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256) (port 587) (Exim 4.90_1 #2) id 1h9F1b-0007xG-OX for freebsd-arm@freebsd.org; Wed, 27 Mar 2019 21:19:51 +0100 Date: Wed, 27 Mar 2019 21:19:49 +0100 From: Manuel =?iso-8859-15?Q?St=FChn?= To: freebsd-arm@freebsd.org Subject: Re: efi-loader ignores dtb files? Message-ID: <20190327201949.GA71432@freebsd-t450.fritz.box> References: <20190327192320.GA64908@freebsd-t450.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) X-Originated-At: 79.217.245.48!31151 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 20:22:07 -0000 On Wed, Mar 27, 2019 at 02:35:26PM -0500, Kyle Evans wrote: >On Wed, Mar 27, 2019 at 2:26 PM Manuel Stühn wrote: >> >> While trying to get FreeBSD 12.0 up and running on a NanoPI NEO2 >> (aarch64 Allwinner H5) I'm stumbling over issues with >> loader/loader.conf. FreeBSD starts fine, but it uses the >> devicetree-blob provided by uboot/EFI. I've tried to load the FreeBSD >> one by adding these lines to loader.conf: >> >> sun50i-h5-nanopi-neo2.dtb_load="YES" >> sun50i-h5-nanopi-neo2.dtb_type="dtb" >> >> and put the dtb file into /boot/dtb/sun50i-h5-nanopi-neo2.dtb, but this >> did not work at all. It got completely ignored by loader. The rest of >> the file was read and applied correctly (kernel-modules i'd added for >> testing purposes were loaded correctly). >> >> I tried to load it by hand like this: >> >> load -t dtb sun50i-h5-nanopi-neo2.dtb >> >> which worked, the dtb file was loaded and used. After consulting >> loader.conf(5) i found this way to load modules: >> >> dtbfile_load="YES" >> dtbfile_type="dtb" >> dtbfile_name="sun50i-h5-nanopi-neo2.dtb" >> >> and this finally triggered loader(8) to actually load the dtb. >> Unfortunatley the problem occurred again when i tried to add overlays. >> Those are, again, not recognized at all: >> >> /boot/loader.conf: >> fdt_overlays="sun50i-nanopi-neo2-codec.dtbo,sun50i-nanopi-neo2-sid.dtbo,sun50i-nanopi-neo2-ths.dtbo" >> >> Any ideas? > >Yes- for your first problem, loader doesn't recognize a period as a >valid module name, so those directives would not have gotten >recognized as modules to load. > >I'm not sure off-hand why fdt_overlays were not recognized. I would >drop to loader prompt and double check that it actually ended up in >the environment, but I don't see any reason off-hand that it wouldn't. >It might be a good idea to drop to loader prompt and trigger overlay >application. No output at all? Output right after the screen-cleaning: Loading kernel... /boot/kernel/kernel text=0x8dec2b data=0x181cf8+0x7998d4 syms=[0x8+0x11dc60+0x8+0x11017c] Loading configured modules... sun50i-h5-nanopi-neo2.dtb.../boot/dtb/sun50i-h5-nanopi-neo2.dtb size=0x587a /boot/entropy.../boot/entropy size=0x1000 Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB from loaded file '/boot/dtb/sun50i-h5-nanopi-neo2.dtb'. EHCI failed to shut down host controller. EHCI failed to shut down host controller. ---<>--- Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-RELEASE #25 5e1256de69f(feature/NanoPI-NEO2)-dirty: Wed Mar 27 18:32:11 CET 2019 root@nanopi-neo2:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) VT: init without driver. Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) [...] >> BTW, is there a way to keep the u-boot logs printed before the >> FreeBSD-boot-menu gets drawn? The console gets cleared and erases some >> (valuable?) information. I was always to slow to stop the boot right >> after the last line of u-boot and the first of EFI. > >Any reason you need to keep the loader menu? Only for debugging puroposes. I would've liked to see what the output was right before the screen got cleared. I tried to disable the menu but this did now stop the clearing. > Disabling it >(beastie_disable="YES") and lack of password prompts will stop the >screen clearing in recent-ish versions of the lua scripts from head. > >Thanks, > >Kyle Evans Thanks! -- Manuel From owner-freebsd-arm@freebsd.org Thu Mar 28 02:53:49 2019 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 B2D2515673A6 for ; Thu, 28 Mar 2019 02:53:49 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.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 86D3F76E0C; Thu, 28 Mar 2019 02:53:48 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2S2rjuq092442; Wed, 27 Mar 2019 19:53:45 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2S2rjfC092441; Wed, 27 Mar 2019 19:53:45 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201903280253.x2S2rjfC092441@gndrsh.dnsmgr.net> Subject: Re: efi-loader ignores dtb files? In-Reply-To: To: Kyle Evans Date: Wed, 27 Mar 2019 19:53:45 -0700 (PDT) CC: =?UTF-8?Q?Manuel_St=C3=BChn?= , "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-Rspamd-Queue-Id: 86D3F76E0C X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.20 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.46)[0.456,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.91)[0.909,0]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.93)[0.931,0]; IP_SCORE(0.01)[ip: (0.08), ipnet: 69.59.192.0/19(0.04), asn: 13868(0.02), country: US(-0.07)]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; FREEMAIL_CC(0.00)[freenet.de]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 02:53:49 -0000 > On Wed, Mar 27, 2019 at 2:26 PM Manuel St?hn wrote: > > > > While trying to get FreeBSD 12.0 up and running on a NanoPI NEO2 > > (aarch64 Allwinner H5) I'm stumbling over issues with > > loader/loader.conf. FreeBSD starts fine, but it uses the > > devicetree-blob provided by uboot/EFI. I've tried to load the FreeBSD > > one by adding these lines to loader.conf: > > > > sun50i-h5-nanopi-neo2.dtb_load="YES" > > sun50i-h5-nanopi-neo2.dtb_type="dtb" > > > > and put the dtb file into /boot/dtb/sun50i-h5-nanopi-neo2.dtb, but this > > did not work at all. It got completely ignored by loader. The rest of > > the file was read and applied correctly (kernel-modules i'd added for > > testing purposes were loaded correctly). > > > > I tried to load it by hand like this: > > > > load -t dtb sun50i-h5-nanopi-neo2.dtb > > > > which worked, the dtb file was loaded and used. After consulting > > loader.conf(5) i found this way to load modules: > > > > dtbfile_load="YES" > > dtbfile_type="dtb" > > dtbfile_name="sun50i-h5-nanopi-neo2.dtb" > > > > and this finally triggered loader(8) to actually load the dtb. > > Unfortunatley the problem occurred again when i tried to add overlays. > > Those are, again, not recognized at all: > > > > /boot/loader.conf: > > fdt_overlays="sun50i-nanopi-neo2-codec.dtbo,sun50i-nanopi-neo2-sid.dtbo,sun50i-nanopi-neo2-ths.dtbo" > > > > Any ideas? > > Yes- for your first problem, loader doesn't recognize a period as a > valid module name, so those directives would not have gotten > recognized as modules to load. > > I'm not sure off-hand why fdt_overlays were not recognized. I would > drop to loader prompt and double check that it actually ended up in > the environment, but I don't see any reason off-hand that it wouldn't. > It might be a good idea to drop to loader prompt and trigger overlay > application. No output at all? > > > BTW, is there a way to keep the u-boot logs printed before the > > FreeBSD-boot-menu gets drawn? The console gets cleared and erases some > > (valuable?) information. I was always to slow to stop the boot right > > after the last line of u-boot and the first of EFI. > > Any reason you need to keep the loader menu? Disabling it > (beastie_disable="YES") and lack of password prompts will stop the > screen clearing in recent-ish versions of the lua scripts from head. Oh, we need to document that as a debugging assist, the screen clear wipes off sometimes usefull information that is very hard to capture unless in a vm with screen recorder. > Thanks, > Kyle Evans And thank you Kyle, for all the good work, -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Thu Mar 28 04:42:41 2019 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 8C5C715438FF for ; Thu, 28 Mar 2019 04:42:41 +0000 (UTC) (envelope-from sanpei.ml@gmail.com) Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1D9D83803; Thu, 28 Mar 2019 04:42:39 +0000 (UTC) (envelope-from sanpei.ml@gmail.com) Received: by mail-pf1-x444.google.com with SMTP id 9so10739982pfj.13; Wed, 27 Mar 2019 21:42:39 -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; bh=aZTUzvW9Sc5F1dJRIKfOIMLs4gb2m+joMDBATTA7Ajc=; b=QDHzM7Oih++KNQmTnkUHsi9BWqKs+X7voAF/v0NySc9me0jL/Ng/sYw95badOWnmtz LlDXeE8qdhoRQJNrr2wrMo5gmnWH+hRzyZaBsfHlV8V6AvjcZrfsa3euqgv3zEhm/jhY 6pPwiIzYdxJ+uRAxXqwwuHcBTF36Ui3CDFX15fyK45yCzwxddkAvjxNg1X02cG7UvNFx dLbDj8zXjZWhqUi9hWIzWDI8UxpCQDYDYLHZbXX/1Ugqt1D/LJxD64Kh11ZBIFjYppxF iYbW5YAktT1diB4R82zVPDGOhOXEO3VlVz35/dahbBPkREQWGFrSSw/d6EFSIu9Lmlgw AQwA== 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=aZTUzvW9Sc5F1dJRIKfOIMLs4gb2m+joMDBATTA7Ajc=; b=LfIbLaa16sNX7buE/2LtMYUyfo4Lm5l3QruJaz6j2pxzsimpa6PtNqEIrCfSYLK6j3 2s2XqHF5Ie32pF8xrCwLel/XtqzRBNfXL1zoGju39HJOepe+LunNC+cH/SVDQOnCzsQr 8HWZj3fG5dDPXHdzRfovzh1cyI/drtsbCl89IiIZXoKdd3CwqrPAYf33mNz+9qPYIB3u EIupbfN2LHWqmdL+tS6I2n7/mChblNJs+LrCp+hhf2VAK4RSW2a60fVU7tfNiayUNRCZ iOhwuBQitrMhMeWnBR5n8o6S2JFkOOwL55rFSox+sRdKBXZjIAlwXJgdTg5u2WeSfG1G 2C5Q== X-Gm-Message-State: APjAAAWkIDBlWMP0+kzDWbdeKXrt+NnLmXbte0ZCSuGmNBPfzLoy7kG4 kT+SXjrgA6CHuxiFQgIBYvaI6HWsnUWNrdteg1UUgA== X-Google-Smtp-Source: APXvYqwaIgsJIOwj9koZewKO5COEF/xV2w56AMds+0uB9JIEZac+OJAhRQHEZyQILfJnhIw7PWgszszupc+NpEgxfgY= X-Received: by 2002:a62:41dc:: with SMTP id g89mr37965064pfd.109.1553748158079; Wed, 27 Mar 2019 21:42:38 -0700 (PDT) MIME-Version: 1.0 References: <4f421a5f-c09d-46a4-8d45-4f7e5e3b2e40@Spark> <1545061176.76088.73.camel@freebsd.org> In-Reply-To: From: Yoshiro MIHIRA Date: Thu, 28 Mar 2019 13:42:26 +0900 Message-ID: Subject: Re: FreeBSD-12.0-current not booting on hummingboard To: Ian Lepore , freebsd-arm , radovan@putec.sk X-Rspamd-Queue-Id: A1D9D83803 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=QDHzM7Oi; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sanpeiml@gmail.com designates 2607:f8b0:4864:20::444 as permitted sender) smtp.mailfrom=sanpeiml@gmail.com X-Spamd-Result: default: False [-3.82 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[4.4.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; IP_SCORE(-0.54)[ip: (2.37), ipnet: 2607:f8b0::/32(-2.87), asn: 15169(-2.15), country: US(-0.07)]; NEURAL_HAM_SHORT(-0.27)[-0.270,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 04:42:41 -0000 Hi. I'm trying to boot 13-current image on Hummingboard. Finally I could boot GENERIC kernel with some loader options. /boot/loader.conf.local hw.regulator.disable_unused=3D0 sdma-imx6q-to1.fwo_load=3D"YES" sdma-imx6q-to1.fwo_type=3D"firmware" put sdma-imx6q-to1.fwo on /boot/kernel directory. ------------------------------------------------------------ background of above settings. I found below message, that's the way kernel could not mount microSD as root partition. >mmc1: CMD8 failed, RESULT: 1 >mmc1: ACMD41 failed, RESULT: 4 1) hw.regulator.disable_unused=3D0 >From boot message, I found below one. So currently I set above value(DON'T disable sd regulator). >regulator: shutting down v_sd 2) load firmware for sdma GENERIC kernel has sdma driver, but there is no firmware and firmware loader module. Maybe there is bad side effect for mmc1. Currently above loader.conf.local is only load firmware image. >sdma0: Can't get firmware. P.S. I replaced and used old u-boot(11.0-RELEASE). P.S2. I can use IMX6 Kernel config without issue(because thos modules doen not included in kernel). Yours Yoshiro.MIHIRA 2019=E5=B9=B43=E6=9C=8825=E6=97=A5(=E6=9C=88) 22:39 Yoshiro MIHIRA : > Hi all, > > I have Hummingboard-i2. > I tested FreeBSD-12.0-RELEASE image. > > Unfortunately, I have two issues. > > 1) u-boot issue. > > Maybe latest u-boot does not support Hummingboard-i2. I use old u-boot > which is included 11.0-RELEASE. > > From sysutils/u-boot-cubox-hummingboard/pkg-descr: > > >As of this writing,the changes in this fork have not been rolled back in= to upstream U-Boot. > > 2) GENERIC kernel issue > > GENERIC kernel could not boot[NG]. If I use IMX6 kernel config, I can boo= t > it. > > boot messages as blow: > https://www.sanpei.org/~sanpei/tmp/12.0-RELEASE-with-11.0-uboot-NG > > If I have time, I will try to find out the reason and to support GENERIC > kernel on Hummingboard. > > Yours > Yoshiro MIHIRA > > 2018=E5=B9=B412=E6=9C=8818=E6=97=A5(=E7=81=AB) 0:40 Ian Lepore : > >> On Sun, 2018-12-16 at 17:34 +0100, Radovan Ptec wrote: >> > Hi there, >> > >> > I've tried installing FreeBSD-12.0-RELEASE on hummingboard, however >> > it seems to >> > be broken,same problem with RC3. Can't test with earlier RC as I >> > didn=E2=80=99t >> > downloaded one and I can=E2=80=99tfind them anymore. >> > >> > 11.2 armv6 is working as expected, upgrading to 12.0 from source as >> > armv6 is >> > also working asexpected. >> > >> > Sorry, no serial console available, I've managed to fry it some time >> > ago. >> > After connecting HDMI I see following output in loop (adresses >> > change): >> > >> > pc : [<1792640c>] lr : [<4ff9f403>] >> > reloc pc : [<1782640c>] lr : [<17826403>] >> > sp : 4f672d08 ip : 4f59 fp : 4f5769dc >> > r10: 4ffb3f02 r9 : 4f57 r8 : 4ff9f40c >> > r7 : 4f89b250 r6 : 4f89 r5 : 4ffc10e r4 : ffffffff >> > r3 : 9ff01ce5 r2 : 9ff0 r1 : 4ffb3f02 r0 : 0000005e >> > Flags: nzCv IRQs on FIQs on Mode SVC_32 >> > Code: f00968a0 b918f866 68e04641 ffb2f7ff (e7ef6824) >> > data abort >> > >> > At this point I'm not sure how to proceed with adressing this issue, >> > or how to debug >> > the problem.Any hints? >> > >> > Thank you! >> > radovan >> >> Nothing in freebsd creates output that looks like that. I think that >> must be u-boot that is crashing and generating that report. But I don't >> have anything useful to add beyond that observation. >> >> -- Ian >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> > From owner-freebsd-arm@freebsd.org Thu Mar 28 13:06:57 2019 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 47252155CB2B for ; Thu, 28 Mar 2019 13:06:57 +0000 (UTC) (envelope-from per@hedeland.org) Received: from outbound1g.eu.mailhop.org (outbound1g.eu.mailhop.org [52.28.6.212]) (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 272DD6FB47 for ; Thu, 28 Mar 2019 13:06:52 +0000 (UTC) (envelope-from per@hedeland.org) ARC-Seal: i=1; a=rsa-sha256; t=1553777441; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=KwqpeWxEnNElo14hEL6UmMZ99lgcIVqGmjJk9JXMWo82b0AOHHWesaB6PjFw1Qj/YEesiugg+cHTX QztqM7NolEzoZwueBX2ojYhDwRp7aK7xNQKT8McUK13hODtLEyP+Cpaek1Ai6tO7pEdWJ820+sOmJC LyxXOgG8zvAKsb97Tp/GNJ2yGBc+mJjADOGrEN5L2suxkdaxih5lgdV7ksTWc+oUxi2n1TuA1gwUFv BWQgTG9nyROsB6UZ0n4+Eln6NNx/hcva6L+42QEyJtKquxkXO86KJ/L4WA37ovz0FrXnEjflCTVasr 4pVRDG2LslcSv/SZ4sLjQ+8XuDGRejA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:mime-version:date:message-id:cc: subject:from:to:dkim-signature:from; bh=mEkXS6SqelzBtWNm1L8GdmFxGy6Ew0zDUmDgTJ8kGXg=; b=lmx/mP3lWjQsxOTfVuFuxAea/iwuo7NbC6h3et0MDrQvof6iCzsEnt74yuDBl+ZdymHCNnNIAOnuK XwtKbW853JSjcAfupS8KGjNSMz5uP5W4tI78Rf+abujibnSbdc2mSVDbLNtx0GU/mJVFaoi5par2LN W5ExLd8ikrVPtF/sdGYgwiT4gtRSN3YCeV6b1L7fCF9onsOcAFeBrTSECvML/iAIus7EYpwXw2sape jW6KNrVeOxiQnv7u88SWzd5CNTOMb+BuylTYe+C85sj+O3FH2kldhr7IxRYr+VvT7vfCP+oAYEmBQ9 ieTrw+z8J9/nI5161A9duMmQ3ZUDUAQ== ARC-Authentication-Results: i=1; outbound3.eu.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.155.78; dmarc=none header.from=hedeland.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:mime-version:date:message-id:cc: subject:from:to:from; bh=mEkXS6SqelzBtWNm1L8GdmFxGy6Ew0zDUmDgTJ8kGXg=; b=dUafAj1ezjnNt39JGDWjdsUlCCE//pxBW3Z1rDZE5CChDJ2ThDGUxjX7B9XlsZApwlCZ+/0+XTZYB 2JEhDs8JJr1U5WcqFJDnhin67OUdvrJNt9mdHz/dA/sJaoXhn7aDGC3FYk6wK0hQ7+leXsoYFV2FQp hjt2Lf84p8ZVWuTcFq//b2SOoz2tT4Tko3KCqX5FHgK/Y4rrUogEiXw8ybgJ6BF2tZcjkdZzMPKqRo PfAoINVEh2SdsG+gZVA8RMz6UI9M043+mEW8cnWfS80Iwxax8OqADlGKsd4Pf/vd+TYmcf0o6fMdKu mKsFfPop5viJL9Rjr7dgru3aFF9cw7Q== X-MHO-RoutePath: cGVyaGVkZWxhbmQ= X-MHO-User: 16af662b-5158-11e9-908b-352056dbf2de X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 81.228.155.78 X-Mail-Handler: DuoCircle Outbound SMTP Received: from hedeland.org (unknown [81.228.155.78]) by outbound3.eu.mailhop.org (Halon) with ESMTPSA id 16af662b-5158-11e9-908b-352056dbf2de; Thu, 28 Mar 2019 12:50:39 +0000 (UTC) Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id x2SCocjN053181 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 28 Mar 2019 13:50:38 +0100 (CET) (envelope-from per@hedeland.org) To: freebsd-arm@freebsd.org From: Per Hedeland Subject: How to force host mode for RPi Zero USB? Cc: freebsd-questions@freebsd.org Message-ID: <222dd329-e0d5-31ad-512a-898040c44c1c@hedeland.org> Date: Thu, 28 Mar 2019 13:50:38 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 272DD6FB47 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outbound.mailhop.org header.s=dkim-high header.b=dUafAj1e X-Spamd-Result: default: False [-3.54 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[outbound.mailhop.org:+]; RCPT_COUNT_TWO(0.00)[2]; MX_GOOD(-0.01)[hedeland.org,mx2.mailhop.org]; NEURAL_HAM_SHORT(-0.96)[-0.961,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-0.28)[asn: 16509(-1.31), country: US(-0.07)]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_ALLOW(-1.00)[i=1]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:16509, ipnet:52.28.0.0/16, country:US]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; R_DKIM_ALLOW(-0.20)[outbound.mailhop.org:s=dkim-high]; RECEIVED_SPAMHAUS_PBL(0.00)[78.155.228.81.zen.spamhaus.org : 127.0.0.11]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[hedeland.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[212.6.28.52.list.dnswl.org : 127.0.20.0]; R_SPF_NA(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 13:06:57 -0000 Hi, I have a 4-port USB hub that attaches directly to the RPi Zero board: http://www.uugear.com/product/zero4u/ . This seems to work fine on FreeBSD - as long as I have an OTG adapter/cable connected to the then otherwise unused data port on the Zero, which is a quite annoying requirement IMHO. Without it, the FreeBSD USB stack uses device mode (as described in the handbook), and (of course) doesn't even see the add-on hub. According to the hub documentation (http://www.uugear.com/doc/Zero4U_UserManual.pdf), "Linux" uses host mode by default, and requries a DT overlay to use device mode. The FreeBSD automatic switching is arguably more elegant, but is IMHO inferior in a case like this (it's of course also impossible to make any USB devices work when connected to the Zero data port *without* an OTG adapter/cable). So, as $SUBJECT - surely there is a way to force host mode? --Per Hedeland From owner-freebsd-arm@freebsd.org Thu Mar 28 14:44:00 2019 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 A745B155F808; Thu, 28 Mar 2019 14:44:00 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD12C74D2F; Thu, 28 Mar 2019 14:43:58 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [176.74.212.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D03332603F3; Thu, 28 Mar 2019 15:43:49 +0100 (CET) Subject: Re: How to force host mode for RPi Zero USB? To: Per Hedeland , freebsd-arm@freebsd.org Cc: freebsd-questions@freebsd.org References: <222dd329-e0d5-31ad-512a-898040c44c1c@hedeland.org> From: Hans Petter Selasky Message-ID: Date: Thu, 28 Mar 2019 15:43:22 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <222dd329-e0d5-31ad-512a-898040c44c1c@hedeland.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: DD12C74D2F X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.43 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[selasky.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[mail.turbocat.net]; NEURAL_HAM_SHORT(-0.91)[-0.914,0]; IP_SCORE(-3.21)[ip: (-9.42), ipnet: 88.99.0.0/16(-4.68), asn: 24940(-1.93), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 14:44:00 -0000 On 3/28/19 1:50 PM, Per Hedeland wrote: > Hi, > > I have a 4-port USB hub that attaches directly to the RPi Zero board: > http://www.uugear.com/product/zero4u/ . This seems to work fine on > FreeBSD - as long as I have an OTG adapter/cable connected to the then > otherwise unused data port on the Zero, which is a quite annoying > requirement IMHO. Without it, the FreeBSD USB stack uses device mode > (as described in the handbook), and (of course) doesn't even see the > add-on hub. > > According to the hub documentation > (http://www.uugear.com/doc/Zero4U_UserManual.pdf), "Linux" uses host > mode by default, and requries a DT overlay to use device mode. The > FreeBSD automatic switching is arguably more elegant, but is IMHO > inferior in a case like this (it's of course also impossible to make > any USB devices work when connected to the Zero data port *without* an > OTG adapter/cable). > > So, as $SUBJECT - surely there is a way to force host mode? > Hi, You can add a "dr_mode" property to the DWC OTG driver instance and set it to "host". --HPS From owner-freebsd-arm@freebsd.org Thu Mar 28 16:35:00 2019 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 68040156246F for ; Thu, 28 Mar 2019 16:35:00 +0000 (UTC) (envelope-from per@hedeland.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (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 60000807FB for ; Thu, 28 Mar 2019 16:34:58 +0000 (UTC) (envelope-from per@hedeland.org) ARC-Seal: i=1; a=rsa-sha256; t=1553789928; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=wB0BwRd+oDl/+KMYsHiZTG/dHvG9VtHs+oOt4DvZ5fBht8NaOhUeqtC2GuSTRxzwmPKvhCNG186wd Xm/V071BjWDXDwKQ1+Uxay9aNM8IjaBjNsS30kYKWZ8MaMHvkaG05i6cwP5vT6tFsGPKHCoyB2b3zv oTw5COJFCEz1AjmJniA7S/iklvPuD/A1787O3v09sddb295N2RyGa3BaKpigUbIj8FSqPTVtvcdJOa HcINio2lW7H2yLYjqSn0LlIFU36ziIE5SrMO/yVvaHSpIctjbnkeLtqVvyczt6cqy4I/pKaMak+ghw LebKjWOEROaHf1gbFTovK3lRCa3Hvcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:dkim-signature:from; bh=SKIPT2fax7cQD6JobdiUZNDzIe4YN//cOTmFhf8snfQ=; b=BTUZcU4pmhWOGruqgy1xZoqIHcd3p64w/NOGY+d60yYYsiHFq2hS0jn2eTFfh56mpXQe7Llf+g96G jfYebHT09G9R+QeO3zHRXEm5Rsb8yFxGLrhw/Cy3QoIgjROUQ1bdzY/y0/VHNJzWWrT/trRiAHwaKK 0SpVdLuomqnYjK2KPNTurMeGLN21qLdisCNL5jeBPWqwOOD9WJUIiF9feGqu2WqxzMTZfl8ZkHSEYU cM4mX3wLSVHCBhprV1duUv4cg/o/rcANf5xn7RxlczzzcAQ4Wc5pLONcCA/krr1fNxq9a1hPyUcHQ+ xd54gyI10jlOtwl4Wg/94KfxSO5OShg== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.155.78; dmarc=none header.from=hedeland.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:from; bh=SKIPT2fax7cQD6JobdiUZNDzIe4YN//cOTmFhf8snfQ=; b=UfWIeQL452+ZoUVZBfmBxH50tyKgSxSi1NPigjbJ5V3DvLmCuBSPBrHeM6kxz1fRrHWkCciqCX9oq Mg0wOzBI7RB/ZtXotGRrGJ7WnPnTXWicBAIQduUNrGxGt1DR93OxTkHgAmVB6T8NtOYlVCcgURdkEK 2JBFffIb9q7sd8t/RK8TBCzWV4Cc6DPBSVaciso9qj7RqMXzkato8UkCu1rSH6sClbARzXOFYhGq6U o1/zKhfZqodRFbm8CPzaDw2YzFwRK3qtYBmRbqjUcmLvc26BMYziLVL9/vqFY+CCUU1W7JBoa0tkKZ ghKUq/nZmciQuvTztfE9W3Az33Ols5g== X-MHO-RoutePath: cGVyaGVkZWxhbmQ= X-MHO-User: 271714d8-5175-11e9-befd-af03bedce89f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 81.228.155.78 X-Mail-Handler: DuoCircle Outbound SMTP Received: from hedeland.org (unknown [81.228.155.78]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 271714d8-5175-11e9-befd-af03bedce89f; Thu, 28 Mar 2019 16:18:46 +0000 (UTC) Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id x2SGIfFo053624 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 28 Mar 2019 17:18:41 +0100 (CET) (envelope-from per@hedeland.org) Subject: Re: How to force host mode for RPi Zero USB? To: Hans Petter Selasky , freebsd-arm@freebsd.org Cc: freebsd-questions@freebsd.org References: <222dd329-e0d5-31ad-512a-898040c44c1c@hedeland.org> From: Per Hedeland Message-ID: <7f6d9c20-42b0-1f47-dc49-2394c3da7cab@hedeland.org> Date: Thu, 28 Mar 2019 17:18:41 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 60000807FB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outbound.mailhop.org header.s=dkim-high header.b=UfWIeQL4 X-Spamd-Result: default: False [-4.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[outbound.mailhop.org:+]; MX_GOOD(-0.01)[cached: hedeland.org]; NEURAL_HAM_SHORT(-0.95)[-0.952,0]; RECEIVED_SPAMHAUS_PBL(0.00)[78.155.228.81.zen.spamhaus.org : 127.0.0.11]; IP_SCORE(-1.24)[ipnet: 54.148.0.0/15(-4.81), asn: 16509(-1.31), country: US(-0.07)]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_ALLOW(-1.00)[i=1]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[outbound.mailhop.org:s=dkim-high]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[hedeland.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[64.219.148.54.list.dnswl.org : 127.0.20.0]; R_SPF_NA(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 16:35:00 -0000 On 2019-03-28 15:43, Hans Petter Selasky wrote: > On 3/28/19 1:50 PM, Per Hedeland wrote: >> Hi, >> >> I have a 4-port USB hub that attaches directly to the RPi Zero board: >> http://www.uugear.com/product/zero4u/ . This seems to work fine on >> FreeBSD - as long as I have an OTG adapter/cable connected to the then >> otherwise unused data port on the Zero, which is a quite annoying >> requirement IMHO. Without it, the FreeBSD USB stack uses device mode >> (as described in the handbook), and (of course) doesn't even see the >> add-on hub. >> >> According to the hub documentation >> (http://www.uugear.com/doc/Zero4U_UserManual.pdf), "Linux" uses host >> mode by default, and requries a DT overlay to use device mode. The >> FreeBSD automatic switching is arguably more elegant, but is IMHO >> inferior in a case like this (it's of course also impossible to make >> any USB devices work when connected to the Zero data port *without* an >> OTG adapter/cable). >> >> So, as $SUBJECT - surely there is a way to force host mode? >> > > Hi, > > You can add a "dr_mode" property to the DWC OTG driver instance and set it to "host". Uh.... - OK, so I looked at the dwc2-overlay.dts that Linux uses, stripped it down to what I guessed was the bare minimum, changed its dr_mode = "otg" to dr_mode = "host": -------------------------------- /dts-v1/; /plugin/; /{ compatible = "brcm,bcm2708"; fragment@0 { target = <&usb>; __overlay__ { dr_mode = "host"; }; }; }; -------------------------------- - compiled it, put it in /boot/msdos/overlays, and added a dtoverlay= line for it in /boot/msdos/config.txt - and it worked!:-) Thanks a lot! Um, I don't suppose there is a simpler way, like adding a line to /boot/loader.conf? --Per From owner-freebsd-arm@freebsd.org Thu Mar 28 18:06:16 2019 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 D985615647F6 for ; Thu, 28 Mar 2019 18:06:15 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [195.4.92.92]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0DE984ABA; Thu, 28 Mar 2019 18:06:14 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.163] (helo=mjail0.freenet.de) by mout2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.90_1 #2) id 1h9ZPi-00024F-A1; Thu, 28 Mar 2019 19:06:06 +0100 Received: from [::1] (port=50274 helo=mjail0.freenet.de) by mjail0.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1h9ZPi-0008Bq-8g; Thu, 28 Mar 2019 19:06:06 +0100 Received: from sub7.freenet.de ([195.4.92.126]:50404) by mjail0.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1h9ZNc-0003e4-Dp; Thu, 28 Mar 2019 19:03:56 +0100 Received: from p4fd9f268.dip0.t-ipconnect.de ([79.217.242.104]:43459 helo=freebsd-t450.fritz.box) by sub7.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256) (port 465) (Exim 4.90_1 #2) id 1h9ZNc-0008BU-6i; Thu, 28 Mar 2019 19:03:56 +0100 Date: Thu, 28 Mar 2019 19:03:55 +0100 From: Manuel =?ISO-8859-1?Q?St=FChn?= To: Kyle Evans Cc: "freebsd-arm@freebsd.org" Subject: Re: efi-loader ignores dtb files? Message-Id: <20190328190355.1459c85b48211905f8a3e04a@freenet.de> In-Reply-To: References: <20190327192320.GA64908@freebsd-t450.fritz.box> 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-Originated-At: 79.217.242.104!43459 X-Rspamd-Queue-Id: D0DE984ABA X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of freebsdnewbie@freenet.de designates 195.4.92.92 as permitted sender) smtp.mailfrom=freebsdnewbie@freenet.de X-Spamd-Result: default: False [-2.17 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.4.92.0/23]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[freenet.de]; MX_GOOD(-0.01)[cached: emig.freenet.de]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.81)[-0.807,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[92.92.4.195.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[freenet.de]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:5430, ipnet:195.4.0.0/16, country:DE]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.954,0]; RCVD_COUNT_FIVE(0.00)[5]; RECEIVED_SPAMHAUS_PBL(0.00)[104.242.217.79.zen.spamhaus.org : 127.0.0.10]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freenet.de]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-0.50)[ip: (-0.87), ipnet: 195.4.0.0/16(-0.83), asn: 5430(-0.79), country: DE(-0.01)]; RWL_MAILSPIKE_POSSIBLE(0.00)[92.92.4.195.rep.mailspike.net : 127.0.0.17] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 18:06:16 -0000 On Wed, 27 Mar 2019 14:35:26 -0500 Kyle Evans wrote: > On Wed, Mar 27, 2019 at 2:26 PM Manuel St=FChn = wrote: > > > > While trying to get FreeBSD 12.0 up and running on a NanoPI NEO2 > > (aarch64 Allwinner H5) I'm stumbling over issues with > > loader/loader.conf. FreeBSD starts fine, but it uses the > > devicetree-blob provided by uboot/EFI. I've tried to load the FreeBSD > > one by adding these lines to loader.conf: > > > > sun50i-h5-nanopi-neo2.dtb_load=3D"YES" > > sun50i-h5-nanopi-neo2.dtb_type=3D"dtb" > > > > and put the dtb file into /boot/dtb/sun50i-h5-nanopi-neo2.dtb, but this > > did not work at all. It got completely ignored by loader. The rest of > > the file was read and applied correctly (kernel-modules i'd added for > > testing purposes were loaded correctly). > > > > I tried to load it by hand like this: > > > > load -t dtb sun50i-h5-nanopi-neo2.dtb > > > > which worked, the dtb file was loaded and used. After consulting > > loader.conf(5) i found this way to load modules: > > > > dtbfile_load=3D"YES" > > dtbfile_type=3D"dtb" > > dtbfile_name=3D"sun50i-h5-nanopi-neo2.dtb" > > > > and this finally triggered loader(8) to actually load the dtb. > > Unfortunatley the problem occurred again when i tried to add overlays. > > Those are, again, not recognized at all: > > > > /boot/loader.conf: > > fdt_overlays=3D"sun50i-nanopi-neo2-codec.dtbo,sun50i-nanopi-neo2-sid.dt= bo,sun50i-nanopi-neo2-ths.dtbo" > > > > Any ideas? >=20 > Yes- for your first problem, loader doesn't recognize a period as a > valid module name, so those directives would not have gotten > recognized as modules to load. Should it work without period (it does not)? sun50i-h5-nanopi-neo2_load=3D"YES" sun50i-h5-nanopi-neo2_type=3D"dtb" > I'm not sure off-hand why fdt_overlays were not recognized. I would > drop to loader prompt and double check that it actually ended up in > the environment, but I don't see any reason off-hand that it wouldn't. I tried to load the overlays from loader prompt by hand like this: load -t dtbo sun50i-nanopi-neo2-codec.dtbo load -t dtbo sun50i-nanopi-neo2-sid.dtbo load -t dtbo sun50i-nanopi-neo2-ths.dtbo and they got applied correctly and the corresponding devices appeared in th= e OS. As another test I did was to not load the base dtb file via loader.conf but= to use the one provided by u-boot/EFI.=20 The output looked like this [...] Using DTB provided by EFI at 0x47ef8000. Loading DTB overlays: 'sun50i-nanopi-neo2-codec.dtbo,sun50i-nanopi-neo2-sid= ,sun50i-nanopi-neo2-ths.dtbo' /boot/dtb/overlays/sun50i-nanopi-neo2-codec.dtbo size=3D0x11a /boot/dtb/overlays/sun50i-nanopi-neo2-sid.dtbo size=3D0x1f5 /boot/dtb/overlays/sun50i-nanopi-neo2-ths.dtbo size=3D0x3c5 applying DTB overlay '/boot/dtb/overlays/sun50i-nanopi-neo2-codec.dtbo' applying DTB overlay '/boot/dtb/overlays/sun50i-nanopi-neo2-sid.dtbo' applying DTB overlay '/boot/dtb/overlays/sun50i-nanopi-neo2-ths.dtbo' failed to apply overlay: FDT_ERR_NOTFOUND [...] In this case the overlays were found and loaded, but did most likely not ma= tch the u-boot dtb file. Is there an issue with loading overlays in conjunction with manually loadin= g dtb files via loader.conf? > It might be a good idea to drop to loader prompt and trigger overlay > application. No output at all? >=20 > > BTW, is there a way to keep the u-boot logs printed before the > > FreeBSD-boot-menu gets drawn? The console gets cleared and erases some > > (valuable?) information. I was always to slow to stop the boot right > > after the last line of u-boot and the first of EFI. >=20 > Any reason you need to keep the loader menu? Disabling it > (beastie_disable=3D"YES") and lack of password prompts will stop the > screen clearing in recent-ish versions of the lua scripts from head. >=20 > Thanks, >=20 > Kyle Evans --=20 Manuel From owner-freebsd-arm@freebsd.org Thu Mar 28 18:30:31 2019 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 3464E15651DA for ; Thu, 28 Mar 2019 18:30:31 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EF8A859D0 for ; Thu, 28 Mar 2019 18:30:30 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 3C0BD1ED72 for ; Thu, 28 Mar 2019 18:30:30 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f44.google.com with SMTP id r25so14709863lfn.13 for ; Thu, 28 Mar 2019 11:30:30 -0700 (PDT) X-Gm-Message-State: APjAAAXHzVI4mOpdhUqY2XCFJEG95hJW/QOYfmy9fRWM8+gVEea2bsVz biDljBk7y0Ews5NCLVAHGDrI3a+DUf2322k8uIE= X-Google-Smtp-Source: APXvYqwedeMC7XKH2HGi7VYNYiFMD9dfsFkNUAfVkTCDwwyxAz8PjDiUPABTEtYrlAmIvZrVOOWa5/FiKFQU8QqB46Y= X-Received: by 2002:ac2:5305:: with SMTP id c5mr13802431lfh.153.1553797828732; Thu, 28 Mar 2019 11:30:28 -0700 (PDT) MIME-Version: 1.0 References: <20190327192320.GA64908@freebsd-t450.fritz.box> <20190328190355.1459c85b48211905f8a3e04a@freenet.de> In-Reply-To: <20190328190355.1459c85b48211905f8a3e04a@freenet.de> From: Kyle Evans Date: Thu, 28 Mar 2019 13:30:12 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: efi-loader ignores dtb files? To: =?UTF-8?Q?Manuel_St=C3=BChn?= Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 9EF8A859D0 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.99)[-0.990,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 18:30:31 -0000 On Thu, Mar 28, 2019 at 1:06 PM Manuel St=C3=BChn wrote: > > On Wed, 27 Mar 2019 14:35:26 -0500 > Kyle Evans wrote: > > > On Wed, Mar 27, 2019 at 2:26 PM Manuel St=C3=BChn wrote: > > > > > > While trying to get FreeBSD 12.0 up and running on a NanoPI NEO2 > > > (aarch64 Allwinner H5) I'm stumbling over issues with > > > loader/loader.conf. FreeBSD starts fine, but it uses the > > > devicetree-blob provided by uboot/EFI. I've tried to load the FreeBSD > > > one by adding these lines to loader.conf: > > > > > > sun50i-h5-nanopi-neo2.dtb_load=3D"YES" > > > sun50i-h5-nanopi-neo2.dtb_type=3D"dtb" > > > > > > and put the dtb file into /boot/dtb/sun50i-h5-nanopi-neo2.dtb, but th= is > > > did not work at all. It got completely ignored by loader. The rest o= f > > > the file was read and applied correctly (kernel-modules i'd added for > > > testing purposes were loaded correctly). > > > > > > I tried to load it by hand like this: > > > > > > load -t dtb sun50i-h5-nanopi-neo2.dtb > > > > > > which worked, the dtb file was loaded and used. After consulting > > > loader.conf(5) i found this way to load modules: > > > > > > dtbfile_load=3D"YES" > > > dtbfile_type=3D"dtb" > > > dtbfile_name=3D"sun50i-h5-nanopi-neo2.dtb" > > > > > > and this finally triggered loader(8) to actually load the dtb. > > > Unfortunatley the problem occurred again when i tried to add overlays= . > > > Those are, again, not recognized at all: > > > > > > /boot/loader.conf: > > > fdt_overlays=3D"sun50i-nanopi-neo2-codec.dtbo,sun50i-nanopi-neo2-sid.= dtbo,sun50i-nanopi-neo2-ths.dtbo" > > > > > > Any ideas? > > > > Yes- for your first problem, loader doesn't recognize a period as a > > valid module name, so those directives would not have gotten > > recognized as modules to load. > > Should it work without period (it does not)? > > sun50i-h5-nanopi-neo2_load=3D"YES" > sun50i-h5-nanopi-neo2_type=3D"dtb" > Negative, it should not work- anything that isn't a kld that gets `load`d needs full name with extension specified. Supplying sun50i-h5-nanopi-neo2_name (with full name as the value) should be sufficient and fix the above. > > I'm not sure off-hand why fdt_overlays were not recognized. I would > > drop to loader prompt and double check that it actually ended up in > > the environment, but I don't see any reason off-hand that it wouldn't. > > I tried to load the overlays from loader prompt by hand like this: > load -t dtbo sun50i-nanopi-neo2-codec.dtbo > load -t dtbo sun50i-nanopi-neo2-sid.dtbo > load -t dtbo sun50i-nanopi-neo2-ths.dtbo > and they got applied correctly and the corresponding devices appeared in = the OS. > > As another test I did was to not load the base dtb file via loader.conf b= ut to use the one provided by u-boot/EFI. > The output looked like this > [...] > Using DTB provided by EFI at 0x47ef8000. > Loading DTB overlays: 'sun50i-nanopi-neo2-codec.dtbo,sun50i-nanopi-neo2-s= id,sun50i-nanopi-neo2-ths.dtbo' > /boot/dtb/overlays/sun50i-nanopi-neo2-codec.dtbo size=3D0x11a > /boot/dtb/overlays/sun50i-nanopi-neo2-sid.dtbo size=3D0x1f5 > /boot/dtb/overlays/sun50i-nanopi-neo2-ths.dtbo size=3D0x3c5 > applying DTB overlay '/boot/dtb/overlays/sun50i-nanopi-neo2-codec.dtbo' > applying DTB overlay '/boot/dtb/overlays/sun50i-nanopi-neo2-sid.dtbo' > applying DTB overlay '/boot/dtb/overlays/sun50i-nanopi-neo2-ths.dtbo' > failed to apply overlay: FDT_ERR_NOTFOUND > [...] > In this case the overlays were found and loaded, but did most likely not = match the u-boot dtb file. > > Is there an issue with loading overlays in conjunction with manually load= ing dtb files via loader.conf? > Yes, I see a problem -- try something like [0] (not even compile tested, but it should work). I'll start working out a more proper solution. [0] https://people.freebsd.org/~kevans/overlay-hack.diff From owner-freebsd-arm@freebsd.org Thu Mar 28 19:10:45 2019 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 A71211566000 for ; Thu, 28 Mar 2019 19:10:45 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E94986E30 for ; Thu, 28 Mar 2019 19:10:45 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id E33EF1F2F2 for ; Thu, 28 Mar 2019 19:10:44 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f174.google.com with SMTP id r24so17603667ljg.3 for ; Thu, 28 Mar 2019 12:10:44 -0700 (PDT) X-Gm-Message-State: APjAAAWljPkEmZwxcVJ6CfVbGZBpGq1L9IQ3E9bC8sVM4HYJ9M/UijDx SSjBFptCOmwcKOJ92FNCXVwnugyT18ZBCgZ2hkY= X-Google-Smtp-Source: APXvYqxsKwAqOKTTRmUP1cqsPwlaZeWDIH/eE6wVz04alxWGC3YFPLRzbCz5ZVZ1dBVPPvfbr8AAz/qorLdRyneFpaU= X-Received: by 2002:a2e:8991:: with SMTP id c17mr6737671lji.83.1553800243433; Thu, 28 Mar 2019 12:10:43 -0700 (PDT) MIME-Version: 1.0 References: <20190327192320.GA64908@freebsd-t450.fritz.box> <20190328190355.1459c85b48211905f8a3e04a@freenet.de> In-Reply-To: From: Kyle Evans Date: Thu, 28 Mar 2019 14:10:27 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: efi-loader ignores dtb files? To: =?UTF-8?Q?Manuel_St=C3=BChn?= Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4E94986E30 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.99)[-0.990,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 19:10:46 -0000 On Thu, Mar 28, 2019 at 1:30 PM Kyle Evans wrote: > > On Thu, Mar 28, 2019 at 1:06 PM Manuel St=C3=BChn wrote: > > > > On Wed, 27 Mar 2019 14:35:26 -0500 > > Kyle Evans wrote: > [... snip ...] > > > I'm not sure off-hand why fdt_overlays were not recognized. I would > > > drop to loader prompt and double check that it actually ended up in > > > the environment, but I don't see any reason off-hand that it wouldn't= . > > > > I tried to load the overlays from loader prompt by hand like this: > > load -t dtbo sun50i-nanopi-neo2-codec.dtbo > > load -t dtbo sun50i-nanopi-neo2-sid.dtbo > > load -t dtbo sun50i-nanopi-neo2-ths.dtbo > > and they got applied correctly and the corresponding devices appeared i= n the OS. > > > > As another test I did was to not load the base dtb file via loader.conf= but to use the one provided by u-boot/EFI. > > The output looked like this > > [...] > > Using DTB provided by EFI at 0x47ef8000. > > Loading DTB overlays: 'sun50i-nanopi-neo2-codec.dtbo,sun50i-nanopi-neo2= -sid,sun50i-nanopi-neo2-ths.dtbo' > > /boot/dtb/overlays/sun50i-nanopi-neo2-codec.dtbo size=3D0x11a > > /boot/dtb/overlays/sun50i-nanopi-neo2-sid.dtbo size=3D0x1f5 > > /boot/dtb/overlays/sun50i-nanopi-neo2-ths.dtbo size=3D0x3c5 > > applying DTB overlay '/boot/dtb/overlays/sun50i-nanopi-neo2-codec.dtbo' > > applying DTB overlay '/boot/dtb/overlays/sun50i-nanopi-neo2-sid.dtbo' > > applying DTB overlay '/boot/dtb/overlays/sun50i-nanopi-neo2-ths.dtbo' > > failed to apply overlay: FDT_ERR_NOTFOUND > > [...] > > In this case the overlays were found and loaded, but did most likely no= t match the u-boot dtb file. > > > > Is there an issue with loading overlays in conjunction with manually lo= ading dtb files via loader.conf? > > > > Yes, I see a problem -- try something like [0] (not even compile > tested, but it should work). I'll start working out a more proper > solution. I've devised a solution that's a little less hacky at [1]. It separates out the loading of overlays from platform_load_dtb into its own platform_load_overlays. I've left it as a platform-specific thing instead of lifting it into the common fdt bits for two reasons: 1.) We still technically support setting fdt_overlays in the U-Boot environment and honoring that, and 2.) Not all FDT platforms support overlays as they've not been tested, so it's probably best to nop it there for now just in case... If we're ok with dropping #1 (probably not even used, but we don't have a way of measuring usage there) and OK with adding untested overlay support to powerpc/{ofw,kboot} then this diff drops dramatically and the calls to fdt_platform_load_overlays get replaced with fdt_load_dtb_overlays calls. > [0] https://people.freebsd.org/~kevans/overlay-hack.diff [1] http://people.freebsd.org/~kevans/overlay-lesshack.diff From owner-freebsd-arm@freebsd.org Thu Mar 28 20:53:09 2019 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 7687915695A4 for ; Thu, 28 Mar 2019 20:53:09 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [195.4.92.92]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88D6D8BE96; Thu, 28 Mar 2019 20:53:07 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.163] (helo=mjail0.freenet.de) by mout2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.90_1 #2) id 1h9c1G-0002MX-03; Thu, 28 Mar 2019 21:53:02 +0100 Received: from [::1] (port=55150 helo=mjail0.freenet.de) by mjail0.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1h9c1F-0004ax-VR; Thu, 28 Mar 2019 21:53:01 +0100 Received: from sub7.freenet.de ([195.4.92.126]:35416) by mjail0.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.90_1 #2) id 1h9bz7-0003jg-LF; Thu, 28 Mar 2019 21:50:49 +0100 Received: from p4fd9f268.dip0.t-ipconnect.de ([79.217.242.104]:14622 helo=freebsd-t450.fritz.box) by sub7.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256) (port 465) (Exim 4.90_1 #2) id 1h9bz7-0002Q4-Eg; Thu, 28 Mar 2019 21:50:49 +0100 Date: Thu, 28 Mar 2019 21:50:48 +0100 From: Manuel =?ISO-8859-1?Q?St=FChn?= To: Kyle Evans Cc: "freebsd-arm@freebsd.org" Subject: Re: efi-loader ignores dtb files? Message-Id: <20190328215048.9dccb364c7ccac59f77bb98f@freenet.de> In-Reply-To: References: <20190327192320.GA64908@freebsd-t450.fritz.box> <20190328190355.1459c85b48211905f8a3e04a@freenet.de> 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-Originated-At: 79.217.242.104!14622 X-Rspamd-Queue-Id: 88D6D8BE96 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of freebsdnewbie@freenet.de designates 195.4.92.92 as permitted sender) smtp.mailfrom=freebsdnewbie@freenet.de X-Spamd-Result: default: False [-1.82 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[freenet.de]; R_SPF_ALLOW(-0.20)[+ip4:195.4.92.0/23]; MV_CASE(0.50)[]; MX_GOOD(-0.01)[emig.freenet.de,emig.freenet.de,emig.freenet.de,emig.freenet.de]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.43)[-0.433,0]; RCVD_IN_DNSWL_LOW(-0.10)[92.92.4.195.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[freenet.de]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:5430, ipnet:195.4.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[104.242.217.79.zen.spamhaus.org : 127.0.0.10]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991,0]; RCVD_COUNT_FIVE(0.00)[5]; SUBJECT_ENDS_QUESTION(1.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freenet.de]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-0.49)[ip: (-0.84), ipnet: 195.4.0.0/16(-0.81), asn: 5430(-0.77), country: DE(-0.01)]; RWL_MAILSPIKE_POSSIBLE(0.00)[92.92.4.195.rep.mailspike.net : 127.0.0.17] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 20:53:09 -0000 On Thu, 28 Mar 2019 14:10:27 -0500 Kyle Evans wrote: > On Thu, Mar 28, 2019 at 1:30 PM Kyle Evans wrote: > > > > On Thu, Mar 28, 2019 at 1:06 PM Manuel St=FChn wrote: > > > > > > On Wed, 27 Mar 2019 14:35:26 -0500 > > > Kyle Evans wrote: > > [... snip ...] > > > > I'm not sure off-hand why fdt_overlays were not recognized. I would > > > > drop to loader prompt and double check that it actually ended up in > > > > the environment, but I don't see any reason off-hand that it wouldn= 't. > > > > > > I tried to load the overlays from loader prompt by hand like this: > > > load -t dtbo sun50i-nanopi-neo2-codec.dtbo > > > load -t dtbo sun50i-nanopi-neo2-sid.dtbo > > > load -t dtbo sun50i-nanopi-neo2-ths.dtbo > > > and they got applied correctly and the corresponding devices appeared= in the OS. > > > > > > As another test I did was to not load the base dtb file via loader.co= nf but to use the one provided by u-boot/EFI. > > > The output looked like this > > > [...] > > > Using DTB provided by EFI at 0x47ef8000. > > > Loading DTB overlays: 'sun50i-nanopi-neo2-codec.dtbo,sun50i-nanopi-ne= o2-sid,sun50i-nanopi-neo2-ths.dtbo' > > > /boot/dtb/overlays/sun50i-nanopi-neo2-codec.dtbo size=3D0x11a > > > /boot/dtb/overlays/sun50i-nanopi-neo2-sid.dtbo size=3D0x1f5 > > > /boot/dtb/overlays/sun50i-nanopi-neo2-ths.dtbo size=3D0x3c5 > > > applying DTB overlay '/boot/dtb/overlays/sun50i-nanopi-neo2-codec.dtb= o' > > > applying DTB overlay '/boot/dtb/overlays/sun50i-nanopi-neo2-sid.dtbo' > > > applying DTB overlay '/boot/dtb/overlays/sun50i-nanopi-neo2-ths.dtbo' > > > failed to apply overlay: FDT_ERR_NOTFOUND > > > [...] > > > In this case the overlays were found and loaded, but did most likely = not match the u-boot dtb file. > > > > > > Is there an issue with loading overlays in conjunction with manually = loading dtb files via loader.conf? > > > > > > > Yes, I see a problem -- try something like [0] (not even compile > > tested, but it should work). I'll start working out a more proper > > solution. >=20 > I've devised a solution that's a little less hacky at [1]. It > separates out the loading of overlays from platform_load_dtb into its > own platform_load_overlays. I've left it as a platform-specific thing > instead of lifting it into the common fdt bits for two reasons: >=20 > 1.) We still technically support setting fdt_overlays in the U-Boot > environment and honoring that, and > 2.) Not all FDT platforms support overlays as they've not been tested, > so it's probably best to nop it there for now just in case... >=20 > If we're ok with dropping #1 (probably not even used, but we don't > have a way of measuring usage there) and OK with adding untested > overlay support to powerpc/{ofw,kboot} then this diff drops > dramatically and the calls to fdt_platform_load_overlays get replaced > with fdt_load_dtb_overlays calls. >=20 > > [0] https://people.freebsd.org/~kevans/overlay-hack.diff >=20 > [1] http://people.freebsd.org/~kevans/overlay-lesshack.diff Thank you for your patches. I've been trying patch[1] but unfortunately it seems to not work for me. Due to my lack of knowledge on how to only build and install /usr/src/stand I've built+installed both kernel+world, but the described behavior did not change; still no overlays when defining a dtb file in loader.conf. --=20 Manuel=20 From owner-freebsd-arm@freebsd.org Thu Mar 28 21:22:19 2019 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 274BB156A1CD for ; Thu, 28 Mar 2019 21:22:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (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 08FD48CDE0 for ; Thu, 28 Mar 2019 21:22:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: jBavYx8VM1mS72ohBpqebC8hCH5kIZiV0fnrfY9txoIRXvDBegK0BruhEz4ohIP gZnDAyyonW.jfLOu6OMwFMUeg2FFXnlZaqvsA25ajtOSeL3tk.TrKJfVuuJ.iaXeku1uTaTwTcCY v__hH8HXV9tln2oVZWBGJm0dkevfRH9_Pm_pGoG8ccdu1QbQ6qgv4AC8mB9PBqeaQd2az_J7q_ZU Xj8c6wUVX4HcPT097Ug1.KAHA6bc3NNh.qwaVE8yAibV5wYuFE4WNqD4rFN4Leh6ulr.QlM1kWLk 3xPIDOSJjD0zUOiwC5NGfBvuGn9YfMV0vktLOIR59w3GHysKALDTFQ1qXb020W7Texln_krfkF1t sg1usH0Lbw5Hehe_KNgojibMwXM_evw4KiAkqowvGWOlnkAS5orDH6QbBn5Yju.YBJU2ubgG83Xa DotbY94vqtR1EXBbM1I9movt16F7AyEidmK.pf0tmq.VeUCjoUclKkSMkGV5N2ztZ2os..hwv17q PezM1xp4RnFPbxIO0Y.ZoAIkvyJy_98sriTi_Nkzo0XGAxzEyCv4w2Sqrtlo.8LbgRRSf8UiLALB w2abCD7ChfUCvWIRiUG1ZkrzGp8lPdfC9N1ohGkfPmoDhcqV4in9fyzmzh0O.4aDHTUxeI2smIbs 1h26ABt9se8l2MiHUdlMlKZu7BvpStlUS_0W2YTpQgI5ytPMi4qN44ATaZIS4qoxb1x0LlA2VYNJ KhuDShgessi3SDpgGPomQ5mZjg8sglWwTRxuzxZirzXhXChWMN3QRMs01oyTb_1y.QJNuhHg38k5 S.ox7w9i.TIrW9t0hJt2ZEByjtrPkc_d7ZYIVrjjn_jMtJXkcNf99DCJj.84pRLS8g23N4EXhNBu M9fU2FFxJn00fEPlOFwJ7R66c2_8LRJep51VfNnEN5AxVDkp0G29YI4Rtai.JwEe1D8qzgB49QFP DNlJCIXWkGdQZpSdwAftlg21.U9T51yrbVOTZOr7TVtQ0lj.YsDv_u7pE3h2PX97IwCZGpomvFgQ _fp76mqmdV312QvnAbDE9FCl4BFd65yawBwFXBfgKw04m1u0bABN5omvtT6eFTRksqrsqTajluQ- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 28 Mar 2019 21:22:11 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp428.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 333d6019923ac1f129434859045a25d3; Thu, 28 Mar 2019 21:22:10 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: file's output for aarch64 vs. other architectures: version 1 (SYSV) instead of version 1 (FreeBSD)? Message-Id: <3965C797-6347-409C-BA35-4DA38C41CE74@yahoo.com> Date: Thu, 28 Mar 2019 14:22:09 -0700 To: FreeBSD Toolchain , freebsd-arm X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 08FD48CDE0 X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.92 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(1.96)[ip: (8.21), ipnet: 98.137.64.0/21(0.93), asn: 36647(0.75), country: US(-0.07)]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.41)[-0.407,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.988,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.88)[0.883,0]; RCVD_IN_DNSWL_NONE(0.00)[205.65.137.98.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 21:22:19 -0000 When I buildworld buildkernel, for most architectures that I build I end up with files that end up classified with things like: ELF 32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD) ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (FreeBSD) ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD) and so on. But, for aarch64, I end up with the likes of: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV) ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV) (It may have always been true, but I just noticed because I happened to look at file's output for other reasons.) Why is aarch64 labeled as "SYSV"? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Mar 29 06:34:58 2019 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 69B5B155BC4C for ; Fri, 29 Mar 2019 06:34:58 +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 D724F8165B for ; Fri, 29 Mar 2019 06:34:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id 9352A155BC46; Fri, 29 Mar 2019 06:34:57 +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 7F703155BC45 for ; Fri, 29 Mar 2019 06:34:57 +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 27C3781659 for ; Fri, 29 Mar 2019 06:34:48 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:Date:Message-Id:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:From; bh=tvkCcy2faJcQTfS42y2c6Q3I/YNWtNJPTW+FUO+ueY8=; b=GF6JaTj4zU0D9cvL/AuJFoX6gHsAFO1B7ypmzL6j1FROk1XbQdG4gtbHV/zP0f+jVI+OMXzlaalrUBAd4ScQSR68C+tmUBWYjOS9csky+kicYNMz71mIBkM9x/Dm6JfWiMuMqpmeS6edJ6hxZhoaF301KWmhPdmcvZsymk/Y40wPgqZH1lKHApI0XAaJ6HyyXWVYah/2e5EviZeJNkmw7Wt0gwVpm2jLhg/xOrgzMb2to51o7kLL0ecFg/qlia/ouTbfkj09i1TYIsVjGA7G5li05XU+1id4x9qiQBI4eXVNtANo7KOsuOLdwe2ZFdZXpzLdZtEevKD2fqSBbK6loA==; Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1h9l5y-000M13-Fp for arm@freebsd.org; Fri, 29 Mar 2019 09:34:30 +0300 From: Daniel Braniss 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: network booting allwinner(nanopi) Message-Id: Date: Fri, 29 Mar 2019 09:34:30 +0300 To: "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3445.9.1) X-Rspamd-Queue-Id: 27C3781659 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=GF6JaTj4 X-Spamd-Result: default: False [-3.06 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.984,0]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[huji.ac.il]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-0.74)[ipnet: 132.64.0.0/13(-2.05), asn: 378(-1.64), country: EU(-0.00)]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; MX_GOOD(-0.01)[kabab.cs.huji.ac.il,post.cs.huji.ac.il]; RCVD_IN_DNSWL_NONE(0.00)[210.116.65.132.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_SHORT(-0.52)[-0.523,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:EU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 06:34:58 -0000 Hi, with last weeks head (r345465), I tried - again - to netboot and the old way no longer works usb start setenv loaderdev net boot now it complains allot:-) but no dice. So, is there a way that netboot works? thanks, danny From owner-freebsd-arm@freebsd.org Fri Mar 29 14:00:56 2019 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 39BAE1569A12 for ; Fri, 29 Mar 2019 14:00:56 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C58B192D83 for ; Fri, 29 Mar 2019 14:00:55 +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 DC1EAFBE9 for ; Fri, 29 Mar 2019 14:00:54 +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 x2TE0sNW032709 for ; Fri, 29 Mar 2019 14:00:54 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2TE0srf032705 for freebsd-arm@FreeBSD.org; Fri, 29 Mar 2019 14:00:54 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 236880] dlopen() of .so with tls fails on (32-bit) arm Date: Fri, 29 Mar 2019 14:00:54 +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: emaste@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.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 14:00:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236880 Bug ID: 236880 Summary: dlopen() of .so with tls fails on (32-bit) arm Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: emaste@freebsd.org On amd64, arm64 dlopen()ing a .so with TLS vars succeeds but vars are not initialized; see kib@'s https://reviews.freebsd.org/D19072 for a patch to address that. On (32-bit) arm dlopen() of the TLS .so fails, with or without kib's patch. Test code: https://github.com/emaste/test-tls-initial-exec On amd64 or arm64 without the patch: % make test LD_LIBRARY_PATH. ./app-link foo: 2016 ./app-dlopen *** Signal 11 Stop. On amd64 or arm64 with the patch: % make test LD_LIBRARY_PATH. ./app-link foo: 2016 ./app-dlopen foo: 2016 On armv7 with or without the patch (tested on BeagleBone Black): % make test LD_LIBRARY_PATH. ./app-link foo: 2016 ./app-dlopen dlopen: dlerror() returned NULL, huh? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Mar 29 18:05:07 2019 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 CE02B1570E5E for ; Fri, 29 Mar 2019 18:05:07 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 62D957188F for ; Fri, 29 Mar 2019 18:05:07 +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 A5CE6120AE for ; Fri, 29 Mar 2019 18:05:06 +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 x2TI56Uq066446 for ; Fri, 29 Mar 2019 18:05:06 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2TI56ws066439 for freebsd-arm@FreeBSD.org; Fri, 29 Mar 2019 18:05:06 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 236880] dlopen() of .so with tls fails on (32-bit) arm Date: Fri, 29 Mar 2019 18:05:05 +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 Only Me X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED 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.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 18:05:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236880 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed --- Comment #5 from Ed Maste --- arm-specific issue fixed in commit referenced above and init-exec TLS for dlopened .so now fixed by r345703 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Fri Mar 29 19:36:33 2019 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 9BE49155040A for ; Fri, 29 Mar 2019 19:36:33 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) 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 0150E76720 for ; Fri, 29 Mar 2019 19:36:33 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: by mailman.ysv.freebsd.org (Postfix) id AC0641550404; Fri, 29 Mar 2019 19:36:32 +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 996C61550403 for ; Fri, 29 Mar 2019 19:36:32 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 116D87671D for ; Fri, 29 Mar 2019 19:36:31 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id x2TJaGJM073374 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Mar 2019 20:36:17 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1553888178; bh=sQ1Etw4h+mQdeklrNc1fZuJ/uiPcUK2ckFG/k/3fATg=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=J8LHSYp197ajBeNqp3G21olFviwxdmnOxVrFc1X+bMocjSIfJQADbQ5xqy31VK/aE WkVjbsD0uBxwO6FT+/DOsQ3absDMTpn9X9NkNtZs/PDsuQR9CEWALBTTiaZ6CPj/Hp 71hLgZCn2CuJ6Bvjfo99JIJAjFWOzq/5TQHYAADY= Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id x2TJaCc4041669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Mar 2019 20:36:12 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id x2TJaBaI023888; Fri, 29 Mar 2019 20:36:11 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id x2TJa8AX023887; Fri, 29 Mar 2019 20:36:08 +0100 (CET) (envelope-from ticso) Date: Fri, 29 Mar 2019 20:36:08 +0100 From: Bernd Walter To: Daniel Braniss Cc: "freebsd-arm@freebsd.org" Subject: Re: network booting allwinner(nanopi) Message-ID: <20190329193608.GC99439@cicely7.cicely.de> Reply-To: ticso@cicely.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 12.0-STABLE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-Rspamd-Queue-Id: 116D87671D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 19:36:33 -0000 On Fri, Mar 29, 2019 at 09:34:30AM +0300, Daniel Braniss wrote: > Hi, > with last weeks head (r345465), > I tried - again - to netboot and the old way no longer works > usb start > setenv loaderdev net > boot > > now it complains allot:-) but no dice. > So, is there a way that netboot works? On a Pi1 project I put the following in loader.conf: currdev="net0" This requires the loader.conf to be on the SD card however. I used an UFS partition for that, but I assume that the msdosfs partition would work too as the loader can read that filesystem as well. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Sat Mar 30 15:24:22 2019 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 AB6231554CC5; Sat, 30 Mar 2019 15:24:22 +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 273A38C592; Sat, 30 Mar 2019 15:24:20 +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 x2UFNReI012013 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 Mar 2019 08:23:28 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id x2UFNRvu012012; Sat, 30 Mar 2019 08:23:27 -0700 (PDT) (envelope-from fbsd) Date: Sat, 30 Mar 2019 08:23:27 -0700 From: bob prohaska To: freebsd-ports@freebsd.org, freebsd-arm@freebsd.org Subject: RPI3, error: invalid operand in inline asm: 'rev16 ${0:w}, ${1:w}' Message-ID: <20190330152327.GA11933@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-Rspamd-Queue-Id: 273A38C592 X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [5.51 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(0.13)[ip: (0.50), ipnet: 50.1.16.0/20(0.25), asn: 7065(-0.02), country: US(-0.07)]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_HAS_CURRENCY(1.00)[]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[zefox.net]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.81)[0.807,0]; MX_GOOD(-0.01)[cached: www.zefox.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.93)[0.930,0]; NEURAL_SPAM_MEDIUM(0.75)[0.745,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 15:24:22 -0000 In a recent attempt to compile www/chromium on an RPI3 running r345516 compilation stopped with repeated reports of /usr/include/machine/endian.h:89:19: error: invalid operand in inline asm: 'rev16 ${0:w}, ${1:w}' Chromium compiled on the same host a couple of months ago, but the executable failed on a runtime library error. Now attempts to upgrade stop during compilation. Ports are presently at revision 496949. Thanks for reading, and any guidance. bob prohaska From owner-freebsd-arm@freebsd.org Sat Mar 30 17:54:12 2019 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 49536155BA30; Sat, 30 Mar 2019 17:54:12 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F2D66E2D1; Sat, 30 Mar 2019 17:54:11 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id x2UHocbr014590; Sat, 30 Mar 2019 13:50:39 -0400 Received: from W92EXCAS20.exchange.mit.edu (18.7.71.33) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sat, 30 Mar 2019 13:50:35 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.112]) by W92EXCAS20.exchange.mit.edu ([18.7.71.33]) with mapi id 14.03.0439.000; Sat, 30 Mar 2019 13:50:36 -0400 From: John F Carr To: bob prohaska CC: "freebsd-ports@freebsd.org" , "freebsd-arm@freebsd.org" Subject: Re: RPI3, error: invalid operand in inline asm: 'rev16 ${0:w}, ${1:w}' Thread-Topic: RPI3, error: invalid operand in inline asm: 'rev16 ${0:w}, ${1:w}' Thread-Index: AQHU5wysVg2BgjPU/Ui4D1u3G3LuWKYktxyA Date: Sat, 30 Mar 2019 17:50:35 +0000 Message-ID: <236A3D25-0B4D-46DA-95BA-71DA505CC2E0@exchange.mit.edu> References: <20190330152327.GA11933@www.zefox.net> In-Reply-To: <20190330152327.GA11933@www.zefox.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.9.1.84] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rspamd-Queue-Id: 4F2D66E2D1 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.58 as permitted sender) smtp.mailfrom=jfc@mit.edu X-Spamd-Result: default: False [0.09 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_XOIP(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_HAS_CURRENCY(1.00)[]; DMARC_NA(0.00)[mit.edu]; NEURAL_SPAM_MEDIUM(0.03)[0.033,0]; NEURAL_SPAM_SHORT(0.23)[0.231,0]; NEURAL_HAM_LONG(-0.85)[-0.854,0]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[mit-edu.mail.protection.outlook.com,mit-edu.mail.protection.outlook.com]; IP_SCORE(-0.01)[asn: 3(-0.00), country: US(-0.07)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 17:54:12 -0000 > On Mar 30, 2019, at 11:23 , bob prohaska wrote: >=20 > In a recent attempt to compile www/chromium on an RPI3 running r345516 > compilation stopped with repeated reports of=20 >=20 > /usr/include/machine/endian.h:89:19: error: invalid operand in inline asm= : 'rev16 ${0:w}, ${1:w}' >=20 > Chromium compiled on the same host a couple of months ago, but the=20 > executable failed on a runtime library error. Now attempts to upgrade > stop during compilation. Ports are presently at revision 496949. >=20 > Thanks for reading, and any guidance. >=20 > bob prohaska The swap function at that line in sys/arm64/include/endian.h doesn't look r= ight to me. I think it should read __asm("rev16 %w0, %w1\n" : "=3Dr" (ret) : "r" (w)); instead of __asm __volatile("rev16 %w0, %w1\n" : "=3D&r" (ret), "+r" (v)); Two changes: (1) it doesn't need to be volatile because it has no side effe= cts and (2) the constraints and lack of explicit input operand are wrong. = The other swap functions should have similar changes. From owner-freebsd-arm@freebsd.org Sat Mar 30 19:51:36 2019 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 32B64156054A for ; Sat, 30 Mar 2019 19:51:36 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4410734D9 for ; Sat, 30 Mar 2019 19:51:35 +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 CB82D6E for ; Sat, 30 Mar 2019 19:51:34 +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 x2UJpYmF056206 for ; Sat, 30 Mar 2019 19:51:34 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2UJpYEi056205 for freebsd-arm@FreeBSD.org; Sat, 30 Mar 2019 19:51:34 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 236905] LLVM's implementation of __gcc_personality_v0 does not correctly initialise the context Date: Sat, 30 Mar 2019 19:51:34 +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: theraven@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.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 19:51:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236905 Bug ID: 236905 Summary: LLVM's implementation of __gcc_personality_v0 does not correctly initialise the context Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: theraven@FreeBSD.org When __gcc_personality_v0 is invoked (when exceptions unwind through C code that needs to run cleanups), it calls _Unwind_GetLanguageSpecificData: https://github.com/freebsd/freebsd/blob/56c04b0bcfcd116f1b13087ec13bcba2d8d= c7705/contrib/compiler-rt/lib/builtins/gcc_personality_v0.c#L205 This is completely fine on most architectures, but on ARM this tries to map from the context to the exception structure. The GNU extension to the APCS requires that the personality function stores this pointer in the context in register 12 (reserved as a linker scratch register, so never actually used = in unwinding).=20=20 The abstraction layer used in libcxxrt does this automatically: https://github.com/pathscale/libcxxrt/blob/f96846efbfd508f66d91fcbbef5dd808= 947c7f6d/src/unwind-arm.h#L223 It appears that the LLVM implementation of the personality routine does not= do this. This can be fixed by adding: ``` _Unwind_SetGR(context, 12, reinterpret_cast(exceptionObject)= ); ``` on entry to the personality routine. This will want to be done upstream, b= ut we should carry a local patch to compiler-rt (and possibly issue an EN) bec= ause at present any program that tries to throw an exception through C stack fra= mes crashes on ARM. --=20 You are receiving this mail because: You are the assignee for the bug.=