Unipispi (neuron) kernel module on latest raspbian



  • 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.



  • @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.



  • 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.



  • Hi @tomasknot,

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

    Thanks,
    Csaba



  • @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.



  • 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.



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



  • 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.



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



  • @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.