Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Mar 2019 13:13:53 -0600
From:      Ian Lepore <ian@freebsd.org>
To:        "Jedi Tek'Unum" <jedi@jeditekunum.com>, freebsd-arm@freebsd.org
Subject:   Re: Options for FBSD support with LCD device - new project
Message-ID:  <004ddba628b94b80845d8e509ddcb648d21fd6c9.camel@freebsd.org>
In-Reply-To: <4EB5C6C1-7DB9-4DEE-BB23-CD1259581271@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>

next in thread | previous in thread | raw e-mail | index | archive | help
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?004ddba628b94b80845d8e509ddcb648d21fd6c9.camel>