From owner-freebsd-arm@freebsd.org Wed Mar 20 14:56:28 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 B78B5155613B for ; Wed, 20 Mar 2019 14:56:28 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (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 069D56AB79 for ; Wed, 20 Mar 2019 14:56:27 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1553093780; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=ew/KfstEXgrerBzVMs9Y864fcg6uEIpDgNPnQDPGZbV2rl3chK28/LjcuwBDf+pQaR/6RKmZKP3MG Vxo3zEq1OtYeQ6u2X8Ek0+XeSaxNLvOdoU2JpTaww6AcV+Yiak3vb+YPZv5W//9h2EyAYWuu4bSjup y9j9ex6EzR2cD1KwUqegvJjrSNWiPXiuoVVnOn35BvMnDvOunVIA+hA/YoQURmv0OygK/M7j1ImPAe 9ttbmTnmKaGcdy3+bdEtFhtRYCBKzAPLC7+LkAML7+ibgy2FfPXN3cWV8ehBFAubcXRb172sAdWAd2 oB9S1ie7ZEXmDKdhGN+TLsFBXdSgdew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=umDdha8I2PWegq9PrZAT6n8RLb01rRD1Kd459rIAVGw=; b=sfXFttFYK6SeSpMbwqUk95x1gdul8pcRnyttM/086xyheW1K1n85Zks17pUft+t6v6OpdRvvBYapT GdLRBY/kiKDlGp8n612eWZmDQTfYjSeCOK9AKIvKDRP1rDc0pe/mrArpEvnW5mZiK9JnmJKJ/zoMcD dd/H9ers1SENisH1cDWMW+yG3wlqRV/H1tXCDO+8NFoZBd3OQjV2ANfPiVuHSKem2qxobIvRc6Vpf2 pg9cnbBvGMIrneGCPcGCsA3AEra1V3gEHNG+dEkPF1NlRONXHgdCM6z9S1x9VQ4PXl4C4Rho5gXWvW QwhpjS9ZGAY4MXmrjY4+2fWqQsETCvQ== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=umDdha8I2PWegq9PrZAT6n8RLb01rRD1Kd459rIAVGw=; b=bWTWyE5G+k7bmfKKu0FcQBnhq1QadHQhrUr1U+EkgVE2pBlMc8R8Fo48lhVyMx3wFc8fbfn723659 fZDpHq6RfaFSqXHXnvhe0xV2ICUrwMKdLj0ZNiQiInIHRQ4Uram5LJ+5q9+nJdCyARXLhjUZVeeQB8 WM2FXXSBvUMnGU4kbDpLzFznu6sVeCRZ9i/s+2K1PDlHtISVYApC2XBdXcyuHUEiRjoExYj14QXPhd BgcTt5N5pt55dcnfQ/uqu6Rs5atS/0MZqhzYdPs/yxMl65PbbIG4p4T85YpsEhs684SjgvBBPk5tFC /9eau2N+gAtM2wKvjurHL72K3WL8wQA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 51077c7e-4b20-11e9-9bb1-1f29e4676f89 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 51077c7e-4b20-11e9-9bb1-1f29e4676f89; Wed, 20 Mar 2019 14:56:19 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x2KEuHkb069099; Wed, 20 Mar 2019 08:56:17 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <17133d06965e61e7e835c5ea7d69ca9762efad7d.camel@freebsd.org> Subject: Re: Options for FBSD support with LCD device - new project From: Ian Lepore To: "Jedi Tek'Unum" Cc: freebsd-arm@freebsd.org Date: Wed, 20 Mar 2019 08:56:17 -0600 In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 069D56AB79 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.988,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Wed, 20 Mar 2019 14:56:29 -0000 On Tue, 2019-03-19 at 09:26 -0500, Jedi Tek'Unum wrote: > On Mar 18, 2019, at 2:57 PM, Ian Lepore 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 ). 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. > The default pin assignments in the dts are completely controlled by linux, and I think effectively by the actual board vendors who create the dts and submit it to linux. We (freebsd) are just a consumer of the dts info, we have to work with whatever they shove down our throats, and continually re-adapt ourselves whenever they change their minds and make arbitrary incompatible changes from one release to the next (which they definitely do). -- Ian