NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Install Moxa Nport 5323 on NI Linux RT

Hi, I'm trying to install the Moxa Nport 5323 drivers on Linux RT (x64 in my case) by starting from the driver available on this page and following the installation instructions located into the README.txt file provided with the driver itself (attached as well). To summarize also below:

-) on the target, I extract the .tgz file under / folder

-) install packagegroup-core-buildessential & ldd packages from our feeds since the readme requires the following softwares:

- kernel 2.4.x or 2.6.x or above and the kernel source package
- gcc-2.7.2.1 or above
- ld.so-1.7.14 or above
- libc.so-5 or above
- binutils-2.7.0 or above
- make-3.74 or above
- gunzip-1.2.4 or above
- gawk-3.1.1.9 or above
- openssl-0.9.8a or above (For Secure Real COM Mode only)

 

-) run  source /usr/local/natinst/tools/versioning_utils.sh 
-) run setup_versioning_env 


-) run /tmp/moxa/mxisnt command. Here's the first error I get

 

make -C /lib/modules/4.1.15-rt17-4.0.0f0/build SUBDIRS=/tmp/moxa modules
make[1]: *** /lib/modules/4.1.15-rt17-4.0.0f0/build: No such file or directory. Stop.
Makefile:65: recipe for target 'module' failed
make: *** [module] Error 2

 

-) I tried to create the /lib/modules/4.1.15-rt17-4.0.0f0/build folder and try again

 

admin@NI-CVS-1458RT-01AF6922:~# /tmp/moxa/mxinst

===============================================================================
Copyright (C) 2002-2012 Moxa Inc.
All Rights Reserved.

MOXA NPort Server Real TTY Driver V1.18 Installation.
System Imformation: Kernel 4.1.15-rt17-4.0.0f0; Machine x86_64.
===============================================================================


Tar files, please wait ... OK!
Building driver...

If you want to use secure communication with target,
you might choose [y] to enable the SSL function.
Note: This function support RealCOM with secure mode only.
Do you want to enable secure function? [y/N].

make -C /lib/modules/4.1.15-rt17-4.0.0f0/build SUBDIRS=/tmp/moxa modules
make[1]: Entering directory '/lib/modules/4.1.15-rt17-4.0.0f0/build'
make[1]: *** No rule to make target 'modules'. Stop.
make[1]: Leaving directory '/lib/modules/4.1.15-rt17-4.0.0f0/build'
Makefile:65: recipe for target 'module' failed
make: *** [module] Error 2
Check Driver...
FAILED !!!

 

How can I solve this error? 

Tx

 

 

 

 

Fabio M.
NI
Principal Engineer
Download All
0 Kudos
Message 1 of 9
(6,271 Views)

Hi Fabio,

 

The error messages that you're seeing are due to the Moxa download attempting to build kernel modules by looking for the needed headers/configuration information in the standard location for these things. Unfortunately, the NI Linux RT distribution does not keep the needed resources in the default location, so you will likely need to modify the scripts that the Moxa package comes with to use the tools described in the tutorial here or the video here

0 Kudos
Message 2 of 9
(6,260 Views)

Update: i tried to look into the makefile of the driver and found out that the line that starts the make process is:

 

$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

 

I set KDIR to /var/volatile/tmp/headers/kerne and changed SUBDIRS with M ending up with 

 

$(MAKE) -C $(KDIR) M=$(PWD) modules

 

the build fails and I see a new warning saying "LINUX_VERSION_CODE" is not defined. How can I set it? Compiling the same code on a ubuntu 14.04 works fine.

 

 

Fabio M.
NI
Principal Engineer
0 Kudos
Message 3 of 9
(6,198 Views)

Hey all, please discard my last post. I did further analysis and I manage to make the moxa script look to the right location of the kernel symbols. This led me to another issues, that is described by the make output here below:

 

make[1]: Entering directory `/home/tux/Desktop/nilinuxrt/linux'
CC [M] /home/tux/Downloads/moxa/kernel3.x/npreal2.o
In file included from include/linux/spinlock_types.h:19:0,
from include/linux/spinlock.h:81,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from /home/tux/Downloads/moxa/kernel3.x/npreal2.c:39:
/home/tux/Downloads/moxa/kernel3.x/npreal2.c: In function ‘npreal_init_tty’:
include/linux/spinlock_types_rt.h:42:2: error: expected expression before ‘{’ token
{ .lock = __RT_SPIN_INITIALIZER(name.lock), \
^
/home/tux/Downloads/moxa/kernel3.x/npreal2.c:597:22: note: in expansion of macro ‘__SPIN_LOCK_UNLOCKED’
tty_node->tx_lock = __SPIN_LOCK_UNLOCKED(tty_node->tx_lock);
^
make[2]: *** [/home/tux/Downloads/moxa/kernel3.x/npreal2.o] Error 1
make[1]: *** [_module_/home/tux/Downloads/moxa/kernel3.x] Error 2
make[1]: Leaving directory `/home/tux/Desktop/nilinuxrt/linux'
make: *** [module] Error 2
Check Driver...
FAILED !!!

 

it seems that the npreal2.c is designed to use "standard" muxes while our kernel redirects to use rtmutexes instead. For this reason, the following line in npreal2.c file:

 

tty_node->tx_lock = __SPIN_LOCK_UNLOCKED(tty_node->tx_lock);

 

works fine if the __SPIN_LOCK_UNLOCKED is the one defined under spinlock_types.h

#define __SPIN_LOCK_INITIALIZER(lockname) \
{ { .rlock = __RAW_SPIN_LOCK_INITIALIZER(lockname) } }

#define __SPIN_LOCK_UNLOCKED(lockname) \
(spinlock_t ) __SPIN_LOCK_INITIALIZER(lockname)

#define DEFINE_SPINLOCK(x) spinlock_t x = __SPIN_LOCK_UNLOCKED(x)

 

but gives error using the one defined under spinlock_types_rt.h

 

#define __SPIN_LOCK_UNLOCKED(name) \
{ .lock = __RT_SPIN_INITIALIZER(name.lock), \
SPIN_DEP_MAP_INIT(name) }

#define DEFINE_SPINLOCK(name) \
spinlock_t name = __SPIN_LOCK_UNLOCKED(name)

 

Can you give me some guidance to adapt npreal2.c code to adapt to rtmutexes? Is it enough to use rtmutexes or do I expect to encounter other errors, based on your experience?

 

Thanks

 

Fabio

 

Fabio M.
NI
Principal Engineer
0 Kudos
Message 4 of 9
(6,193 Views)

@Chuck_81 wrote:

 

...

Can you give me some guidance to adapt npreal2.c code to adapt to rtmutexes? Is it enough to use rtmutexes or do I expect to encounter other errors, based on your experience?

 ... 


Basically, it comes down to whether or not the locking in the module depends on traditional spinlock behavior of disabling preemption (usually not required for most drivers that use them) or if it simply needs to maintain module state/behavior (read: guarantee that other threads of execution won't interfere with the code protected by the lock, a traditional mutual-exclusion-type requirement for execution).

0 Kudos
Message 5 of 9
(6,185 Views)

Quick update: to make the driver install on NI Linux RT targets (so far it's been tested on 16.0/4.1 and x86_64 cpus) you need to change the way the spinlock init code in the npreal2.c file. One approach could be calling the macro right when the struct that contains it is defined:

 

//static struct npreal_struct npvar_table[NPREAL_PORTS];
static struct npreal_struct npvar_table[NPREAL_PORTS] = {
[0] = {
.tx_lock = __SPIN_LOCK_UNLOCKED(npvar_table[0].tx_lock)}
};

 

Then there are these other small changes to make: 

-) In the makefile, modify the way the KDIR variable is initialized, by letting user to add it as an argument when calling ./mxisnt

 

#KDIR   := /lib/modules/$(shell uname -r)/build
KDIR    ?= /home/tux/Desktop/nilinuxrt/linux

 

-) In mxaddsrv.c and mxloadsrv.c, there's an if statement at the beginning of the code that sets the os variable to identify the distribution type (redhat, debian, etc,) that you're running the script. To make it work on nilinuxrt, you need to move from the linux case to the debian case, to make use of the right init.d directory where to store init scripts.

 

Once you make these changes, you can successfully compile the driver (either on the rt target or through a cross compilation). 

Unfortunately, this is just half of the path to make things work. To be able to map the serial ports (ttyr<xx>) under the nilrt os, you need to recompile the kernel with the LEGACY_PTYS options disabled. You can find it using menuconfig under device drivers -> character devices . Follow the steps detailed here to compile and deploy the new kernel on your linux rt target. 

 

Thanks a lot to BradM for the precious suggestions,

 

Regards

Fabio M.
NI
Principal Engineer
0 Kudos
Message 6 of 9
(6,163 Views)

Why not just using the mainline moxa driver ?

 

https://www.kernel.org/doc/Documentation/serial/moxa-smartio

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 7 of 9
(5,153 Views)

Hello Chuck_81,

 

I am having a similar problem you had: trying to install driver for MOXA nPort 5410 on cRIO-9045.

 

I already tried some things you explaind, but didn't get it working yet.

You set KDIR to /home/tux/Desktop/nilinuxrt/linux. What is in this path? Is there the Kernel Header? And if yes, where can I get the right files from?

 

Would be great, if you could give me some ideas to get the driver installed.

Thanks in advance!

 

BR

Josef

0 Kudos
Message 8 of 9
(3,986 Views)

Hi, find here file that should be correct. What you need to do: 

 

https://1drv.ms/u/s!AurpJeCRcBYcgWhoQUySfgM2Q1r2?e=nrjzY0 

 

-) Download the file

-) on a Linux Machine, or on the cRIo target, unzip the file

-) Follow the steps on the readme.txt to build it. 

 

If you compile on the target, please install these prerequisities:

 

-) on the target, I extract the .tgz file under / folder

-) install packagegroup-core-buildessential & ldd packages from our feeds since the readme requires the following softwares:

- kernel 2.4.x or 2.6.x or above and the kernel source package
- gcc-2.7.2.1 or above
- ld.so-1.7.14 or above
- libc.so-5 or above
- binutils-2.7.0 or above
- make-3.74 or above
- gunzip-1.2.4 or above
- gawk-3.1.1.9 or above
- openssl-0.9.8a or above (For Secure Real COM Mode only)

 

basically referring to my first post.

 

Let us know how it goes.

Fabio M.
NI
Principal Engineer
0 Kudos
Message 9 of 9
(3,935 Views)