Best way to compile Kernel Drivers

[tduffy]

Hello NI Linux Real-Time Comunity,

Has anyone dove into compiling Kernel drivers for the cRIO-9068?  Does NI have a recommended flow for this?  Where can I download the source code to the version of their kernel?  It would be nice to be able to cross compile these, but not necessary.

Also, it looks like the kernel is tainted on my device (out of the box).  Is this because the Kernel is tainted at compile time, or because NI has loaded non-GPL kernel modules into it?

Thanks!

-TD

[BradM]

Many of the NI kernel modules for interacting with NI hardware, e.g. the FPGA, are not GPL and therefore loading those into the kernel "taints the kernel" in kernel developer parlance. When you install NI drivers to the target, they get loaded automatically on boot.

Requests for the kernel source used to build the kernel itself can be made to licensing@ni.com (as per NI Linux Real-Time FAQ). Once you have the source, you need a reasonable cross-compilation setup on a Linux machine in order to compile the kernel as NI ships it (the configuration file that is used can be located at $KERNEL_SOURCE_ROOT/arch/arm/configs/ni_zynq_defconfig, and can be either directly copied to $KERNEL_SOURCE_ROOT/.config or copied-and-expanded with ARCH=arm ... make ni_zynq_defconfig, note that the invocation of the tools will be different depending on what tools you use). Once you have that in place, you can make configuration changes (enable new modules) through something like ARCH=arm ... make menuconfig.

[tduffy]

Thanks for the quick reply Brad!

Can you speak to, or point me to information about putting the code I get from ni up on github?  It would be nice to be able to pull the code down from a central repository rather than needing to go to NI each time someone new wants to pull the source code down.

Thanks again for the quick response.  Any insight into the recomended flow of compiling our own Kernel modules?

Thanks,

-TD

[BradM]

What I can speak to is that we're interested in getting the source up on a central source control system, and we are considering github for this purpose. We'll make any related announcements on these forums as soon as there is something to announce.

[tduffy]

That is great to hear.  I highly recommend github, as it is the central repository for everything opensource (at the moment).  You could also fork from the Linux kernel upstream ( https://github.com/torvalds/linux ), which would be awesome!

Tahnks again Brad.

[s.boria]

Hi tduffy, 

Just a brief message around compiling modules on top of NI kernel. I have successfully cross compiled exotic hardware modules on the kernel : sensoray framegrabbers, FTDI chip based for DIY stuff, wifi dongle 

As I don't have access (to NI Guys I hope to be able to mention "yet" ;-))  to NI kernel patched version, I simply used standard official headers and the "3rd party" module sources (As I don't have my target closed to me, I can't tell you which version I used, but "uname -r" or the even more verbose "cat /proc/version" would provide you this info).

I used the toolchain provided sourcery lite edition, version 2010.09-50 for arm-gnu as a regular basis with NI targets but I made also some tests with the arm gnu 4.4 version and it seems to work also (with -mfloat-abi=softfp)

As I used 3rd party module most of the time, I simply make the module directly. Of course, you can compile a standard module (based on standard kernel as long as you don't have NI src available), using the traditional make with CONFIG_xxx=m flags. Don't forget the ARCH=arm and CROSS_COMPILE=... to avoid problems. Another way would be to create a dummy config file by your own and to fulfil the standard make sequence.

I didn't know if you are using that on day to day basis, so I prefered to give you a whole picture of what can be done.

Hope it helps (or at least answered to your question?) 

Remark

I prefered to use linux host (in a VM) because of dependancies in lib src I had to compile just after the modules (for example libav has a lot of 3rd party dep regarding the options you want to have)... and downloading the proper libs src version is far more easy with your favorite pkg manager. Of course, it could easily work with svn/git/whatever if you prefer. If you want to stay on win, it works also of course, but I would suggest to use msys to avoid silly problems with separator paths aso.

[tduffy]

s.boria, this is great news!!!  Thank you so much for taking the time to put it together.

I agree that compiling on a Linux host is almost always easier.  I will give this a go and report back my successes for sure.  I'll be sure to document my work as well and tag it for the community once complete.

Thank you again for putting this together, I'm excited that the vanila kernel works to compile drivers against for the cRIO-9068!

-TD

[BradM]

Zynq source for 2014: http://download.ni.com/ni-linux-rt/src/

x64 source for 2014: https://github.com/ni/linux

[metux]

Many of the NI kernel modules for interacting with NI hardware, e.g. the FPGA, are not GPL and therefore loading those into the kernel "taints the kernel" in kernel developer parlance. 

For very good reason: there's no guarantee that they will work. And nobody (except the lazy vendor) can ever fix them. Note that kernel modules have to fit exactly to the kernel binary - version, config, etc (there're a lot of things that could go horribly wrong). And of course, it's all a maintenance nightmare.

One of the *MAJOR* problems is that you can never upgrade the kernel on your own (something that I have to do regularily).

For 99.99% of the users, the best choice is never using binary-only modules.

I really wish, more kernel subsystems would be explicitly gpl-only, so those unprofessional and arrogant vendors are driven out of the Linux world.

Last year, I head to personally kill a >10Mio deal from one of my clients for exactly that reason: no (free) drivers.

[metux]

As I don't have access (to NI Guys I hope to be able to mention "yet" ;-))  to NI kernel patched version, I simply used standard official headers and the "3rd party" module sources (As I don't have my target closed to me, I can't tell you which version I used, but "uname -r" or the even more verbose "cat /proc/version" would provide you this info).

Russian roulette.