Date: Tue, 19 Mar 2019 09:26:42 -0500 From: Jedi Tek'Unum <jedi@jeditekunum.com> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: Options for FBSD support with LCD device - new project Message-ID: <CE40E2B5-2244-4EF9-B67F-34A54D71E2E8@jeditekunum.com> In-Reply-To: <ac7d434f16f3a89f5ef247678d6becdbeded5c3f.camel@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 18, 2019, at 2:57 PM, Ian Lepore <ian@freebsd.org> 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 <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=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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CE40E2B5-2244-4EF9-B67F-34A54D71E2E8>