Date: Mon, 18 Mar 2019 13:57:18 -0600 From: Ian Lepore <ian@freebsd.org> To: "Jedi Tek'Unum" <jedi@jeditekunum.com> Cc: freebsd-arm@freebsd.org Subject: Re: Options for FBSD support with LCD device - new project Message-ID: <ac7d434f16f3a89f5ef247678d6becdbeded5c3f.camel@freebsd.org> In-Reply-To: <C68D7E6E-03C1-448F-8638-8BD1717DBF44@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? BTW, bottom-posting replies is the norm on freebsd mailing lists. -- Ian > > On Mar 18, 2019, at 2:13 PM, Ian Lepore <ian@freebsd.org> wrote: > > > > On Mon, 2019-03-18 at 13:59 -0500, Jedi Tek'Unum wrote: > > > I’ve been lurking here for some time. Long time (commercial) unix > > > expert. Not much FBSD. > > > > > > I’m running Linux right now on NanoPi NEO (Allwinner H3) and NEO > > > 2 > > > (Allwinner H5). Not because I love Linux (I don’t) but because it > > > works out of the box including I2C. I’d really like to use FBSD > > > on > > > them. I hope that they will reach the same maturity as BB soon. > > > > > > Perhaps I’m wrong but my impression following this list and > > > searching > > > around is that I2C and SPI are not “out of the box” with FBSD on > > > these platforms. > > > > > > I’m not all that familiar with FDT. I’d like to learn how to > > > master > > > it. If I understood it better I could probably bring anything I > > > needed to life. BUT, that is back burner to actually completing > > > the > > > projects I’m trying to complete (where I just need I2C access > > > from > > > user land). I really need those things to just work out of the > > > box > > > for now - or have clear instructions on how to enable. > > > > > > In short I can’t use FBSD yet because it doesn’t appear ready for > > > these kinds of apps on these devices. I greatly appreciate all > > > the > > > effort that has and is going on to get there. If I had the > > > knowledge > > > I’d love to help, but I don’t currently. > > > > > > Perhaps I’ve just not searched and read enough to find the jewel > > > document that explains all the FDT magic in sufficient detail. By > > > that I mean *current* FDT magic (which is another confusing > > > aspect as > > > things seem to be in flux). > > > > > > Any advice on these matters greatly appreciated. > > > > > > > > > > I'm not sure what would give you that impression about i2c and > > spi. I > > belive they're well-supported on virtually every arm SOC we have > > any > > support for at all (except maybe amlogic/odroid and exynos, both of > > which are rapidly bitrootting from neglect). We have command-line > > tools to read and write data to i2c and spi devices from userland, > > as > > well as programmatic interfaces using ioctl() for higher- > > performance > > needs like a rasterized spi display. > > > > I'm the person who does most of the i2c and spi driver work for all > > of > > freebsd (not just arm), and it's something we use heavily in our > > products at $work, so I tend to stay on top of it. > > > > To enable i2c or spi on any given platform, you usually do have to > > touch some FDT code along the way. That's because almost always, > > the > > pins used by i2c or spi can be used for other things as well, so > > the > > default config (which we get by importing fdt source code from > > linux) > > usually isn't set up to enable those devices. > > > > To enable them you typically have to write and compile a small dts > > overlay and set a variable in /boot/loader.conf to have that > > overlay > > loaded at boot time. None of that is hard, but there is quite a > > bit to > > explain, more than I can do right here in this email in the middle > > of a > > $work day. I guess maybe I should write a wiki page for it. > > > > -- Ian > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ac7d434f16f3a89f5ef247678d6becdbeded5c3f.camel>