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

Mon Mar 25 15:19:58 UTC 2019

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 <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.
> > 
> > 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 at 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 <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.