How to compile and install new FTDI driver on cRIO-9034 with latest kernel

[jmoti]

Hi,

I've got a cRIO-9034 with the following spec:

NI Linux Real-Time intel x64 based

Firmware : 4.0.0f0

Kernel : 4.1.15-rtl17-4.0.0.0f0

FTDI device : FT2232H (VCP)

The current ftdi_sio driver included with the distribution doesn't support the baud rate at 12M, needed by my application. A VCP driver is available on http://www.ftdichip.com/Drivers/VCP.htm but it needs to be compilate.

Unfortunately, the kernel source code are not by default on the cRIO, and NI said to me that the source code for my kernel version are not already available on their website.

I have also tried a cross-compilation with C/C++ Development Tools for NI Linux Real-Time, Eclipse Edition 2014, and it works for a classic software compilation but not for my driver (library issues). I also tried with a 4.1.15 kernel source code, found on a website, but it doesn't work.

Does someone know how I could resolve my issue ?

By advance thank you !!!

[ScotSalmon]

Can you clarify what you mean when you say the source code from the web site doesn't work? You should be using https://github.com/ni/linux/tree/nilrt_pub/16.0/4.1

Also, whom are you referring to when you report that "NI said" that the source code is not available? We need to correct that person.

[jmoti]

Hi ScotSalmon,

Thank you !

I didn't find this branch, I tried the kernel version from kernel.org. About the toolchain for the cross-compilation is it the same for all kernel version, or do I use a specific one ?

Thank you !

[BradM]

Hi there jmoti,

The controller has the kernel headers and configuration files needed to compile an out-of-tree kernel module available on the target (this is required to install different versions of NI drivers to the same controller, e.g. the ability to install RIO 2016 to a LVRT 2015 controller).

However, from a quick glance at the driver listed on the site, it seems to be the same driver as in the kernel source, simply an older version of that driver. Looking at the driver in the kernel, it seems that it supports 12M for the 2232H part that you have, so what issue are you actually seeing?

For reference: https://github.com/ni/linux/blob/nilrt_pub/16.0/4.1/drivers/usb/serial/ftdi_sio.c#L1340

An additional note, according to FTDI's notes on the part, be sure that your level shifting circuitry (if you're doing that) supports the baud rates (and, if you're not shifting, be sure to account for noise when designing)

[BradM]

To more directly answer your question, in case I missed something when looking at the in-kernel driver and compared it to the download link, here's the guide on using NI's tools for rebuilding NI kernel modules for building an out-of-tree kernel module: Tutorial: Adding Kernel Modules on NI Linux Real-Time

[jmoti]

Hi BradM,

In fact, with the current driver version,  if I try to set the 12M baud rate by the web interface, I've got a message indicates the argument is not valid.

If I try in command line, for example : stty -F /dev/ttyUSB0 12000000 I obtain the error message : stty: invalid argument '12000000'

But if I set the baud rate at 9600, for example, I have no error.

Thank you !

[BradM]

Using the web interface, I'm sure there's some built-in limit that applies to the NI UARTs that is being applied to all input values, but I'd need to check with the serial folks.

Digging into the busybox source (what provides stty in NI's shipping image), it too seems to have a limit to the baud rate requested to be set

(ref:

https://git.busybox.net/busybox/tree/coreutils/stty.c?h=1_23_1#n789 ->

https://git.busybox.net/busybox/tree/libbb/speed_table.c#n82 which references

https://git.busybox.net/busybox/tree/libbb/speed_table.c#n22 , which does not go to 12M)

I'd recommend installing the coreutils package to replace busybox's stty with the actual one and test that out

[BradM]

BradM wrote:

...

I'd recommend installing the coreutils package to replace busybox's stty with the actual one and test that out

My apollogies, I just took a look at the coreutils' version of stty and it seems that it, too, has limits tied to the POSIX standard (http://man7.org/linux/man-pages/man3/tcsetattr.3.html).

Digging around, you will probably need to either write some code to directly interact with the serial port for using a non-standard BAUD rate or find someone who's already done this.

[jmoti]

Hi BradM,

But if I write some code, I need to compile it. On a previous post, ScotSalmon indicated the latest source code of the kernel can be found here : https://github.com/ni/linux/tree/nilrt_pub/16.0/4.1 but on the cRIO into which folder I must place the source code ?

I also tried to do a cross-compilation using C/C++ development tools for NI real-time, eclipse edition 2014, but when I compile a code including kernel libraries I have compilation issues (missing lib, variable not declared, ...). So, as this is a 2014 revision, I suppose the latest kernel source code is not included.

Thank you !

[ScotSalmon]

The development tools (Eclipse) are not the kernel source. Their version is not related to the kernel source version. The kernel source is at the github link you quoted, and I wouldn't actually recommend using Eclipse to build it. Eclipse is useful for developing your own libraries and applications, but the Linux kernel has its own build infrastructure included in the source tree, see https://github.com/ni/linux/tree/nilrt_pub/16.0/4.1/Documentation/kbuild for details. I wouldn't recommend trying to build the kernel on your cRIO -- you should have a Linux development host for that, at least a virtual machine on your Windows dev machine if you don't have a Linux dev machine available.

Just to clarify, the "2014" version of C/C++ Development Tools for NI Linux Real-Time, Eclipse Edition is the correct version for developing your own software for our devices versions 2014-2016, as is now (thanks to a recent update) noted in the text of the relevant web page: http://www.ni.com/download/labview-real-time-module-2014/4846/en/ -- but again, I wouldn't personally use that to compile a Linux kernel.