# SPI driver for Raspberry Pi 3 in FreeBSD v-12



## wnb (Aug 9, 2017)

Does anyone know of Documentation or Sample Programs for this interface?

As of aarch64 snapshot of V-12.0-CURRENT r321072 of July 18, several kernel modules showed up in /boot/kernel. kldload spigen.ko creates /dev/spigen0. There's also gpiospi.ko which I have not experimented with. I've hunted for man pages but can't find any...

thanks in advance/bob


----------



## aragats (Aug 9, 2017)

There is a discussion here. 
I haven't dealt with RPi for long time, but for most ARM platforms you have to load a device tree overlay for SPI to expose it to the kernel, see RPi's documentation.
There is a simple patch to the existing DTS in FreeBSD in this email thread (a little bit old though).


----------



## balanga (Aug 9, 2017)

aragats said:


> There is a discussion here.
> I haven't dealt with RPi for long time, but for most ARM platforms you have to load a device tree overlay for SPI to expose it to the kernel, see RPi's documentation.
> There is a simple patch to the existing DTS in FreeBSD in this email thread (a little bit old though).



If this driver gets loaded would I be able to use my PiFace Digital?


----------



## vstemen (Nov 17, 2018)

Hi. We are trying to gain userland access to SPI on the raspberry PI 3 on FreeBSD 12 and FreeBSD 13.0-CURRENT. When we load the spigen.ko kernel module, it successfully loads but no spigen devices appear in /dev.  

 Are there any tricks to this that we are missing?  Does the FDT (flattened device tree) play a role in getting the spigen0 device to appear?


----------



## Phishfry (Nov 17, 2018)

gonzo@ has some samples on github:
https://lists.freebsd.org/pipermail/freebsd-hackers/2017-March/050683.html


----------



## vstemen (Nov 17, 2018)

Phishfry said:


> gonzo@ has some samples on github: https://lists.freebsd.org/pipermail/freebsd-hackers/2017-March/050683.html


Thanks Phishfry, but we had already found the information from gonzo but it is over a year and a half old and we still couldn't find how to make the spigen module create the spigen device in that information.


----------



## aragats (Nov 17, 2018)

vstemen , can you show your device tree? Does it it have SPI related stuff?
I don't have a RPi related *dtbs* handy, but can share a similar thing for BeagleBone Black.


----------



## vstemen (Nov 18, 2018)

aragats, we are not running any device tree blobs, if that is what you mean.  We are just trying to get the low level spigen0.0 and gpigen0.1 devices to appear in /dev.


----------



## aragats (Nov 18, 2018)

vstemen said:


> we are not running any device tree blobs, if that is what you mean.  We are just trying to get the low level spigen0.0 and gpigen0.1 devices to appear in /dev.


The device tree is not a blob, it's a description, you compile it and let your kernel know what hardware you have. There is no other way to tell the kernel what devices are available in your system.


----------



## vstemen (Nov 18, 2018)

Thanks for the reply aragats.  However I still don't quite understand.  We are attaching an ICE40 FPGA on the other end of an SPI.  The SPI devices on the other end can come and go in a fraction of a second.  So we need /dev/spigen0.0 and /dev/spigen0.1 in order to talk to the FPGA to even discover what devices exist.  It's not something that can be known ahead of time and compiled into the kernel.  It must be done in user land.


----------



## aragats (Nov 18, 2018)

vstemen said:


> It's not something that can be known ahead of time and compiled into the kernel.


It's a completely opposite thing, the idea and purpose of device trees is NOT TO HARDCODE into kernel.
In case of ARM platform the kernel is pretty generic for a large class of ARM CPUs, it needs to know what particular peripherals are available and what are their addresses.
In general, the device tree is OS independent.
When you install FreeBSD in your RPi you already have **.dtb* files in  /boot/dtb/ and they are loaded at boot time. They may not provide SPI (or something else) description, and you can load extra overlays by adding them to loader.conf: `fdt_overlays=xyz`.


----------



## vstemen (Nov 21, 2018)

Hi aragats.  OK. We have done a lot more research and finally understand better how it works.  Thanks for the pointers. 

Yes, there is a dtb file in the rpi boot partition, *bcm2710-rpi-3-b.dtb*, and we confirmed it is is being loaded.  SPI is enabled in config.txt with the line,

dtparam=audio=on,i2c_arm=on,spi=on

 sysctl output shows 

dev.gpio.0.pin.11.function: alt0 
dev.gpio.0.pin.10.function: alt0 
dev.gpio.0.pin.9.function: alt0 

alt0 is correct for SPI according to the Broadcom manual. 

Yet no /dev/spigen0.n files appear with the spigen.ko module loaded.

 To confirm, we set spi=off in config.txt for testing, and those three pins changed to 

dev.gpio.0.pin.11.function: input 
dev.gpio.0.pin.10.function: input
dev.gpio.0.pin.9.function: input

 Of course we rebooted between those tests .

 I have attached the device tree with SPI enabled as output by 

`ofwdump -a`

We also tested with the latest snapshot for FreeBSD 13 as of today, 11/20/2018.

*FreeBSD-13.0-CURRENT-arm64-aarch64-RPI3-20181119-r340622.img*


----------



## vstemen (Nov 27, 2018)

Thanks for the information.  I posted an issue report and received more detailed instructions from gonzo which allowed us to finally get it working. 

Here are the instructions

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233489#c1

It did require an overlay that was not yet committed to the kernel sources.
I had to copy and paste the overlay from the diff output on

https://reviews.freebsd.org/D16088

and edit it to remove diff markers.  I didn't see any direct download link.
I have attached the rpi3 overlay source file, *spigen-rpi3.dtso*, to make it easier for others.


----------

