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.