SPI driver for Raspberry Pi 3 in FreeBSD v-12

W

wnb

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
 
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).
 
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?
 
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.
 
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.
 
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.
Click to expand...
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.
 
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.
 
vstemen said:
It's not something that can be known ahead of time and compiled into the kernel.
Click to expand...
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.
 
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
 

Attachments

  • rpi-device-tree.txt
    3.9 KB · Views: 289
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.
 

Attachments

  • spigen-rpi3.dtso.txt
    750 bytes · Views: 295
You must log in or register to reply here.
Back
Top