Date: Tue, 19 Mar 2019 09:55:12 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-arm@freebsd.org Subject: Re: Options for FBSD support with LCD device - new project [[Maybe related: I2c issues on the Pi2]] Message-ID: <f60ea6d2-b696-d896-7bcb-ac628f41f7b8@denninger.net> In-Reply-To: <CE40E2B5-2244-4EF9-B67F-34A54D71E2E8@jeditekunum.com> 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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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. -- Karl Denninger karl@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ [-- Attachment #2 --] 0 *H 010 `He 0 *H 00 H^Ōc!5 H0 *H 01 0 UUS10U Florida10U Niceville10U Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA0 170817164217Z 270815164217Z0{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA0"0 *H 0 h-5B>[;olӴ0~͎O9}9Ye*$ g !ukvʶLzN`jL>MD'7U 45CB+kY`bd~b*c3Ny-78ju]9H euέsӬDؽmgwER?&UURj'}9nWD i`XcbGz \gG=u%\Oi13ߝ4 K44pYQr]Ie/r0+eEޝݖ0C15Mݚ@JSZ(zȏ NTa(25DD5.l<g[[Z arQQ%Buȴ~~`IohRbʳڟu2MS8EdFUClCMaѳ !}ș+2k/bųE,n当ꖛ\(8 WV8 d]b yXw ܊:I39 00 U ]^§Q\ӎ0U #0T039N0b01 0 UUS10U Florida10U Niceville10U Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA @Ui0U 0 0U 0 *H :P U!>vJ n io -#ן]Wyu jǑR̀Q nƇ!G ѦF g\ yLx gw=OPycehf[ }ܷ['4ڝ\[p 6\o.B&JF" ZC{;*o*mcCcLY߾` t*S!(` ]DHP5A~/NPp6=mhk밣'doA$86hm5ӚS@ j ެEgl )0JG`%k35PaC?σ ׳HEt}!P㏏%*BxbQwaKG$6 h¦Mve; [o-Iی& I,Tc ߎ#t wPA@l0P+KXBպT zGv;NcI3&J ĬUPNa?/%W6G۟N000 k#Xd\ =0 *H 0{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA0 170817212120Z 220816212120Z0W1 0 UUS10U Florida10U Cuda Systems LLC10U karl@denninger.net0"0 *H 0 T[I-ΆϏ dn;Å@שy.us~_ZG%<MYd\gvfnsa1'6Egyjs"C [{~ _K Pn+<*pv#Q+H/7[-vqDV^U>f%GX)H.|l`M(Cr >е͇6#odc"YljҦln8@5SA0&ۖ"OGj?UDWZ5 dDB 7k-)9Izs-JAv J 6L$Ն1SmY.Lqw*SH;EF'DĦH]MOgQQ|Mٙג2Z9y@ y]}6ٽeY9Y2xˆ$T=e CǺǵbn֛{j |@LLt1[Dk5:$= ` M 00<+00.0,+0 http://ocsp.cudasystems.net:88880 U 0 0 `HB0U 0 U %0++03 `HB &$OpenSSL Generated Client Certificate0 U %՞V =;bzQ0U #0]^§Q\ӎϡ01 0 UUS10U Florida10U Niceville10U Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA H^Ōc!5 H0 U 0karl@denninger.net0 *H ۠A0-j%--$% g2#ޡ1^>{K+uGE v1ş7Af&b&O; .;A5* U)ND2bF|\= ]<sˋL!wrw٧> YMÄ3\mWR hSv!_zvl? 3_ xU%\^#O*Gk̍YI_&Fꊛ@&1n } ͬ:{hTP3B.;bU8:Z=^Gw8 !k-@xE@i,+'Iᐚ:f hztX7/(hY` O.1}a`%RW^akǂpCAufgDix UTЩ/7}%=jnVZvcF<M= 2^GKH5魉 _O4ެByʈySkw=5@h.0z> W1000{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0 `He E0 *H 1 *H 0 *H 1 190319145512Z0O *H 1B@fd24_ݏ[)1<(O M|e&ߝpZY 3Qk6k,I0l *H 1_0]0 `He*0 `He0 *H 0*H 0 *H @0+0 *H (0 +7100{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0 *H 10{1 0 UUS10U Florida10U Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0 *H gRZx-/"*`0Sãv]+ú gٸZo`iQ_vY` E'lA#;G 6S#y;(B5F/U,Vٗ s?H-[!)mPk A6zj:!? x/gVFm>ܑs&U 3' k ~i : Q2嬗~m9^S $`J: 8ŻK:fX5n]-2یkfpJ+{:Z SԯaKrbɿdP}Pj4q[d(#TҸNO_=nNmacE}ߧ\P1* PMէ_TYy>V\V/;H;̂aqV,APTZ/=*>*Wv5 1 ZG' M.d3NBrz|fk$Zhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f60ea6d2-b696-d896-7bcb-ac628f41f7b8>