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

[Karl Denninger]

On 3/20/2019 10:00, 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?
>
> -- Ian

I don't think so -- there's another report (Bernd Walter on this list)
with a Pi1 running 12-Release and an I2c RTC on it getting the same
messages (and, I assume, the same insane interrupt counts.)

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20190320/52dfe2a9/attachment.bin>