Date: Mon, 25 Mar 2019 16:18:17 +0100 From: Bernd Walter <ticso@cicely7.cicely.de> To: Ian Lepore <ian@freebsd.org> Cc: ticso@cicely.de, Karl Denninger <karl@denninger.net>, 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> In-Reply-To: <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org> References: <e5d42c67-e1f2-ede1-965f-c89226de46da@optiplex-networks.com> <89f5b8d1ab0614ac8d88b5d5f1afc63e640c3c17.camel@freebsd.org> <4EB5C6C1-7DB9-4DEE-BB23-CD1259581271@jeditekunum.com> <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> <C68D7E6E-03C1-448F-8638-8BD1717DBF44@jeditekunum.com> <ac7d434f16f3a89f5ef247678d6becdbeded5c3f.camel@freebsd.org> <CE40E2B5-2244-4EF9-B67F-34A54D71E2E8@jeditekunum.com> <f60ea6d2-b696-d896-7bcb-ac628f41f7b8@denninger.net> <20190319161423.GH57400@cicely7.cicely.de> <52df098fdc0caf5de1879c93239534fffbd49b56.camel@freebsd.org>
index | next in thread | previous in thread | raw e-mail
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 <ian@freebsd.org> 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 <https://groboards.com/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: <NXP PCF8563 RTC> 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 <bernd@bwct.de> http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190325151817.GJ57400>