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