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

Tue Mar 19 14:55:51 UTC 2019

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.

-- 
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/20190319/5e723279/attachment.bin>