Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]]

Mon Mar 25 15:08:22 UTC 2019

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 <ian at 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.

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