Options for FBSD support with LCD device - new project

[Jedi Tek'Unum]

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 Mar 18, 2019, at 2:13 PM, Ian Lepore <ian at 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