A20 can't build Kvaser kernel modules

Started by artur, August 03, 2022, 12:28:53 PM

Previous topic - Next topic

artur

I want to build Kvaser kernel drivers to use their interfaces on A20 LIME2. I did this successfully on my Kubuntu x86 laptop  (5.15.0) and on the raspberry pi (5.10.17).

I installed linux-headers-5.10.105-olimex.

The package is called "Kvaser Linux Drivers and SDK" from here https://www.kvaser.com/download/ The build process is as simple as extracting the tarball and typing "make". It does build the shared libraries correctly but it can't build the kernel modules:
make[1]: Entering directory '/home/olimex/linuxcan/common'
--------------------------------------------------------------------
building kvcommon
Kernel src: /lib/modules/5.10.105-olimex/build
make -C /lib/modules/`uname -r`/build M=/home/olimex/linuxcan/common modules
make[2]: Entering directory '/usr/src/linux-headers-5.10.105-olimex'
  CC [M]  /home/olimex/linuxcan/common/VCanOsIf.o
In file included from ./include/asm-generic/int-ll64.h:11,
                 from ./arch/arm/include/uapi/asm/types.h:5,
                 from ./include/linux/bitops.h:4,
                 from /home/olimex/linuxcan/common/../include/module_versioning.h:69,
                 from /home/olimex/linuxcan/common/VCanOsIf.c:69:
./include/uapi/asm-generic/int-ll64.h:12:10: fatal error: asm/bitsperlong.h: No such file or directory
   12 | #include <asm/bitsperlong.h>
      |          ^~~~~~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [scripts/Makefile.build:280: /home/olimex/linuxcan/common/VCanOsIf.o] Error 1
make[2]: *** [Makefile:1822: /home/olimex/linuxcan/common] Error 2
make[2]: Leaving directory '/usr/src/linux-headers-5.10.105-olimex'
make[1]: *** [/home/olimex/linuxcan/common/../config.mak:172: kv_module] Error 2
make[1]: Leaving directory '/home/olimex/linuxcan/common'
make: *** [Makefile:149: common] Error 2

What am I doing wrong?

lukav

#1
I have the same problem with another software:
make modules -C /lib/modules/5.10.180-olimex/build M=/var/lib/dkms/ttyPos/3.1.6-20220517/build
make[1]: Entering directory '/usr/src/linux-headers-5.10.180-olimex'
  CC [M]  /var/lib/dkms/ttyPos/3.1.6-20220517/build/ttyPos.o
In file included from ./include/asm-generic/int-ll64.h:11,
                from ./arch/arm/include/uapi/asm/types.h:5,
                from ./include/uapi/linux/types.h:5,
                from ./include/linux/types.h:6,
                from ./include/linux/list.h:5,
                from ./include/linux/module.h:12,
                from /var/lib/dkms/ttyPos/3.1.6-20220517/build/ttyPos.h:4,
                from /var/lib/dkms/ttyPos/3.1.6-20220517/build/ttyPos.c:1:
./include/uapi/asm-generic/int-ll64.h:12:10: fatal error: asm/bitsperlong.h: No such file or directory
  12 | #include <asm/bitsperlong.h>
      |          ^~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.build:286: /var/lib/dkms/ttyPos/3.1.6-20220517/build/ttyPos.o] Error 1
make[1]: *** [Makefile:1828: /var/lib/dkms/ttyPos/3.1.6-20220517/build] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.10.180-olimex'
make: *** [Makefile:10: all] Error 2

I think it's problem with the linux-headers-5.10.180-olimex package.

lukav

A little more information I've discovered.
My dkms module seams to build fine using linux-[headers/image]-5.10.0-22-armmp, which I presume was used before, since this is a problem that appears after apt dist-upgrade.
So I dig a little more and found out that the file in question bitsperlong.h do exists in linux-headers-5.10.180-olimex but in a different directory asm-generic.
In linux-headers-5.10.0-22-common the file is in there but it is also in arch/arm/include/generated/uapi/asm/ directory and probably that is why there is no problem there.
I guess is olimex maintainers need to turn some option on when generating the packages so the arch ... generated ... folders to get generated and included in the headers package.

:/usr/src# find -name bitsperlong.h
./linux-headers-5.10.180-olimex/include/asm-generic/bitsperlong.h
./linux-headers-5.10.180-olimex/include/uapi/asm-generic/bitsperlong.h
./linux-headers-5.10.0-22-common/include/asm-generic/bitsperlong.h
./linux-headers-5.10.0-22-common/include/uapi/asm-generic/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/ia64/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/alpha/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/arm64/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/sparc/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/mips/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/powerpc/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/x86/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/parisc/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/riscv/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/s390/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-armmp/arch/arm/include/generated/uapi/asm/bitsperlong.h

stepnut

I have measured 3.3v and 5v on the header. If the diode is burned, shouldn't it be shorted to ground, and I shouldn't be able to measure 3.3v and 5v on the header? - or am I misunderstanding the situation?
(I realized this by examining the diagram)

LubOlimex

What diode, what are you writing about? What is your board? Sorry but I can't seem to find connection to your post and previous posts in this thread.
Technical support and documentation manager at Olimex

meterlabour

#5
Quote from: lukav on July 31, 2023, 08:09:48 PMA little more information I've discovered.
My dkms module seams to build fine using linux-[headers/image]-5.10.0-22-armmp, which I presume was used before, since this is a problem that appears after apt dist-upgrade.
So I dig a little more and found out that the file in question bitsperlong.h do exists in linux-headers-5.10.180-olimex but in a different directory asm-generic.
In linux-headers-5.10.0-22-common the file is in there but it is also in arch/arm/include/generated/uapi/asm/ directory and probably that is why there is no problem there.
I guess is olimex maintainers need to turn some option on when generating the packages so the arch ... generated ... folders to get generated and included in the headers package.

:/usr/src# find -name bitsperlong.h
./linux-headers-5.10.180-olimex/include/asm-generic/bitsperlong.h
./linux-headers-5.10.180-olimex/include/uapi/asm-generic/bitsperlong.h
./linux-headers-5.10.0-22-common/include/asm-generic/bitsperlong.h
./linux-headers-5.10.0-22-common/include/uapi/asm-generic/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/ia64/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/alpha/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/arm64/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/sparc/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/mips/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/powerpc/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/x86/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/parisc/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/riscv/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-common/arch/s390/include/uapi/asm/bitsperlong.h
./linux-headers-5.10.0-22-armmp/arch/arm/include/generated/uapi/asm/bitsperlong.h
I'm unsure what this code has to do with generating kernel modules.