Unipispi (neuron) kernel module on latest raspbian

majorcsa

Hi,

I'm trying to use the latest raspbian stretch (using raspberrypi-kernel 1.20180817-1) with a Neuron L203. I've managed to compile the kernel module from your git repository (https://git.unipi.technology/UniPi/unipi-kernel) with success, using the script within the modules/unipi directory.

The module can be loaded successfully into the kernel, but the only message is:

[  453.707228] unipi: loading out-of-tree module taints kernel.
[  453.710108] UNIPISPI: SPI Driver Registered, Major Version: Version 1.15:2018:08:14

Do I need to do anything else to make this module work and detect the HW?

Thanks in advance,
Csaba

TomasKnot

Hi @majorcsa,

Well done compiling the kernel, it's not entirely trivial! It should be quite easy to get it running now.

As for what's needed: You will need to compile the device tree overlay for the target system as well. You can find a makefile in the "device_tree" folder; it should be possible to run it on all RaspberryPi images (or indeed for any recent Linux system, if necessary). The resulting .dtbo binary then needs to be copied into /boot/overlays and activated by adding the following line to the bottom part of /boot/config.txt

dtoverlay=neuron-spi-new

(replace "neuron-spi-new" with the name of the .dtbo file if you rename it)
This tells the driver system to look for the Neuron device.

Hopefully this helps, don't hesitate to ask if you have any further questions!

majorcsa

@tomasknot Thanks for the quick help, it solved my issue, indeed.
So, now it seems, that neuron could make easily work on a standard raspbian stretch installation, no need to use your custom image.

Do you plan to release binary .deb packages or dkms for the kernel modules and overlay? It would be awesome if I could just install a plain raspian then add an apt-source and install neuron dependencies :)

Thanks for the great work and the quick help,
Csaba

TomasKnot

Hi @majorcsa!

We do indeed have the packages already, all that's needed is to add

deb https://repo.unipi.technology/debian stretch main

to your /etc/apt/sources.list file.

We are still trying to figure out the best way to move our customers over to this system, which is the main reason why we haven't yet officially released it to public; though the apt sources are included on the latest Mervis images as well as all Axons (where the lack of easily-replaceable SD card makes it a practical necessity).

You are welcome to try it out and see how it fits your needs, we have been using the package system internally for quite a while, as can be seen by the number of package versions uploaded to https://repo.unipi.technology/debian/ (it is web browsable).

majorcsa

@tomasknot I forgot to ask: I had to make 2 small changed to be able to compile the module:

diff --git a/modules/unipi/raspbian b/modules/unipi/raspbian
index b48e09d..f9cb26c 100755
--- a/modules/unipi/raspbian
+++ b/modules/unipi/raspbian
@@ -5,7 +5,7 @@
 # for new version checking delete file tmp/versions
 #
 #################################################
-if [ -s tmp/versions ]; then
+if [ ! -s tmp/versions ]; then

Without this change the version file would be created only if it does exist already :)

diff --git a/modules/unipi/src/unipi_tty.c b/modules/unipi/src/unipi_tty.c
index a6aa074..1e21a11 100644
--- a/modules/unipi/src/unipi_tty.c
+++ b/modules/unipi/src/unipi_tty.c
@@ -69,7 +69,7 @@
 
 
 // #undef UNIPI_TTY_TRACE
-#ifdef NEURONSPI_DETAILED_DEBUG
+#if NEURONSPI_DETAILED_DEBUG > 0
 # define unipi_tty_trace(f, args...)   trace_printk(f, ##args)

As the variable is defined but 0 it's still using trace_printk which generated a big fat warning during the kernel load to not to use this module in production. I think it should not be used by default.

Regards,
Csaba

TomasKnot

Hi @majorcsa,

Yes, the variables are disabled on our regular builds, but we do enable them for development purposes. Development builds are somewhat bleeding edge by definition, and so we have these debugging options enabled when using them.

majorcsa

@tomasknot Yes, I think, but you're using

#if NEURONSPI_DETAILED_DEBUG > 0

everywhere to check this debug variable, but in this file there is only an #ifdef which is true as it's really defined with the value 0. So I think, this "debug" part will be included all time even if you have this variable set to 0.

TomasKnot

Oh you are right! Thanks for the bug report; I believe this has been fixed in our staging version already, but I will make sure to check with my coworker who has done so.

majorcsa

Hi @tomasknot,

It's really cool, I'm definitely going to test it!

Thanks,
Csaba

majorcsa

@tomasknot: I made a quick test, and it seems the neuron-kernel package has no version for the newest kernel:

neuron-kernel : Depends: raspberrypi-kernel (= 1.20180703-1) but 1.20180817-1 is to be installed

The neuron-firmware package does not depend on the neuron-kernel package. Is it intentional? I think the firmware is not really usable without the kernel module.

TomasKnot

The latest version is actually renamed unipi-firmware (the neuron packages generally date before Axon, except for neuron-kernel), though that does not answer the question. I believe it should be handled by transitive dependencies through unipi-modbus-tools/unipi-common, but feel free to try it out.

Ultimately the firmware is not necessary as it already comes preloaded however, it's only used for updates.

E:

As for the latest kernel - yes it is intentional, the kernel gets updated quite a bit (the last update, as you can see from the package name, was only 5 days ago) and we cannot guarantee that every new version will work without changes.

majorcsa

As far as I can see, currently there is no up-to-date neuron kernel package available at the moment?

TomasKnot

Yes, there isn't, that is none with the last kernel in raspbian.

It should be noted that the kernel version in Raspbian itself is quite arbitrary, the actual last kernel version is 4.18.4, and e.g. the kernel version in x86/x64 Debian and Raspbian (not to mention other distributions) is wildly different. There isn't anything particularly special about the latest update adopted in Raspbian, and for example Axons use completely different - considerably newer - versions.

It's very different from updates in other operating systems like Windows or OSX, the version adopted in Raspbian last week is over a year old now. There is no need to update the version unless one wants to use or create a driver which uses particular parts of the newer kernel.

You can see the kernel version if you run "uname -a", I believe it is currently 4.14.XYZ. We always freeze the version at the point of the latest package release, much as Raspbian updates the kernel opportunistically when otherwise updating packages in the distribution. The kernel is common to all Linux distributions, whatever the platform.

majorcsa

I'm just curious if you plan to do an automatic release of the neuron-kernel package after raspbian-kernel image update?

TomasKnot

@majorcsa
Unfortunately not, the updates have broken our driver three times within the past year, and so even if it is technically easy to do with a simple build script, it's not feasible for the process to be automated in such a way.

The kernel updates by their nature change the entire API around which our driver is built, often changing things like includes, data structures, macros, function signatures etc. The process is somehow formalised by how the linking process for Linux drivers works, namely the use of a symbol table, but again the table itself changes quite a lot. Not all changes will break the module, but many have.

This is the same reason why Raspbian itself only updates to one version in ~20, and is many updates behind the latest, as it always needs to be tested (and updated) for compatibility.