Date: Wed, 20 Mar 2019 09:00:17 -0600 From: Ian Lepore <ian@freebsd.org> To: 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: <b4bad5eb0571127c7b73b3b0bedd8150b954bf62.camel@freebsd.org> In-Reply-To: <f60ea6d2-b696-d896-7bcb-ac628f41f7b8@denninger.net> References: <ad61a598-53af-02a5-41db-0128da7d1a34@optiplex-networks.com> <CAF19XBLAjP4yKtGSBzA4QdT346Bnbnr8MutQNZgmERLbJkWAyA@mail.gmail.com> <8df902f6-20a3-31c4-71ac-91f5d5fdf50d@optiplex-networks.com> <0ecf23e129ca7ac6a92a01bbb34c03f1ac8c6dc8.camel@freebsd.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b4bad5eb0571127c7b73b3b0bedd8150b954bf62.camel>