Options for FBSD support with LCD device - new project

[Ian Lepore]

On Tue, 2019-03-19 at 09:26 -0500, 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.
> 

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