From owner-freebsd-arm@freebsd.org Tue Mar 19 14:27:03 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8AEAD155243E for ; Tue, 19 Mar 2019 14:27:03 +0000 (UTC) (envelope-from jedi@jeditekunum.com) Received: from a2i644.smtp2go.com (a2i644.smtp2go.com [103.47.206.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D27B5871CC for ; Tue, 19 Mar 2019 14:26:52 +0000 (UTC) (envelope-from jedi@jeditekunum.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=m4fue0.a1-4.dyn; x=1553006512; h=Feedback-ID: X-Smtpcorp-Track:To:Date:Subject:Message-Id:From:Reply-To:Sender: List-Unsubscribe; bh=luryk9BjLdRvzCOJhoZsthCboZOTELMgexWzyPm+jeU=; b=hVGCv2Fr nasDhDyoAQNbm+Tjy8//fbI9e0yTu4SzxW9BAJqnt6NKbfluk99bkA/NBIR7sn+hC0guSQgg4jAxu p7trmxe5KzAMjgl6RrUmzZn/TC4jCY2/0qvwCFZiffD9GClTLNa2NywUxyNFrvtvUsFglQCH1FW++ J0/IPAWzX9lVqGmEEaCZQ7LamniYMHlX+QvTXJrWSHWBOoeXh3M3OY+8mpPVYWq+erhglsK5gUoPf k0eE7+dEGI+hqXotgxTMIHHWv0jrtFoivh+YqptzbfO9qRLu6gpdO2DvPYdpNHfcbC6NGbX16fzyA g/3bVh/SV4q4nQkJ+mhDrts9ng==; Received: from [10.66.228.43] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1h6FhV-ED4wZr-HM; Tue, 19 Mar 2019 14:26:45 +0000 Received: from [10.162.213.37] (helo=takodana.opaxus.net) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1h6FhV-wSEVbL-1I; Tue, 19 Mar 2019 14:26:45 +0000 Received: from [10.0.10.1] (174-20-17-78.mpls.qwest.net [174.20.17.78]) by takodana.opaxus.net (Postfix) with ESMTPSA id A82AB266F0; Tue, 19 Mar 2019 09:26:43 -0500 (CDT) From: Jedi Tek'Unum Message-Id: Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Options for FBSD support with LCD device - new project Date: Tue, 19 Mar 2019 09:26:42 -0500 In-Reply-To: Cc: freebsd-arm@freebsd.org To: Ian Lepore References: <8df902f6-20a3-31c4-71ac-91f5d5fdf50d@optiplex-networks.com> <0ecf23e129ca7ac6a92a01bbb34c03f1ac8c6dc8.camel@freebsd.org> <89f5b8d1ab0614ac8d88b5d5f1afc63e640c3c17.camel@freebsd.org> <4EB5C6C1-7DB9-4DEE-BB23-CD1259581271@jeditekunum.com> <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org> X-Mailer: Apple Mail (2.3445.9.1) X-Smtpcorp-Track: 1h6FhVwSEVPL1m.kLwk1YOlC Feedback-ID: 207158m:207158azGM_-I:207158sDWsPdZzId X-Report-Abuse: Please forward a copy of this message, including all headers, to X-Rspamd-Queue-Id: D27B5871CC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smtpservice.net header.s=m4fue0.a1-4.dyn header.b=hVGCv2Fr X-Spamd-Result: default: False [-3.65 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[smtpservice.net:s=m4fue0.a1-4.dyn]; MX_INVALID(0.50)[greylisted]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[jeditekunum.com]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[smtpservice.net:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_MED(-0.20)[132.206.47.103.list.dnswl.org : 127.0.3.2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; NEURAL_HAM_SHORT(-0.92)[-0.916,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; IP_SCORE(-0.74)[asn: 1299(-3.69), country: EU(-0.00)]; ASN(0.00)[asn:1299, ipnet:103.47.204.0/22, country:EU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 14:27:03 -0000 On Mar 18, 2019, at 2:57 PM, Ian Lepore wrote: >=20 > On Mon, 2019-03-18 at 14:51 -0500, Jedi Tek'Unum wrote: >> My impression wasn=E2=80=99t that support wasn=E2=80=99t there - but = =E2=80=9Cout of the box=E2=80=9D >> configuration wasn=E2=80=99t there. In comparison, I didn=E2=80=99t = have to do >> anything to get I2C enabled in the binary distribution of Linux that >> comes through the manufacturer. >>=20 >> Its the enabling part that isn=E2=80=99t obvious to most people IMO. >>=20 >> 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 =E2=80=9Ccommon place=E2=80=9D (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.) >>=20 >>=20 >> 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. >>=20 >>=20 >=20 > 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. >=20 > 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=E2=80=99t call that crippled. I chose this platform exactly = because of its characteristics - small, fast, cheap. It fits the project = I=E2=80=99m using it for perfectly. In fact, I can see uses for even = smaller (see 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=E2=80=99t 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 (=E2=80=9CFriendlyCore=E2=80=9D based on = UbuntuCore Xenial). IMHO, most =E2=80=9Chobbyists=E2=80=9D would prefer the diversity = approach. I=E2=80=99m completely capable of becoming an expert in FBSD = and this sort of configuration stuff yet it isn=E2=80=99t 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=E2=80=99t pretty - I won=E2=80=99t say more as = everyone reading this has a clear understanding of why that is.