I have a Sound Codec that was added in Kernel 4.9 (NAU8810) and I have a device that runs kernel 3.12.
The provisions of upgrading the kernel to 4.x is very complex, and involves thousands and thousands of units already in the field which logistically is a nightmare, just to add a codec file in.
Is there a way to compile a module like that for 3.12 and run it on 3.12?
Thanks
Related
I am doing embedded system development with my EVM board. And now, i want to release my whole software to others. To get some referrences on how to package my software, i downloaded some other vendors' linux SDK.
The thing confused me is if its vendor modified the linux kernel, instead of releasing the SDK with a dirty kernel directly they all have a original clean kernel along with a patch containing this modification.
So,that is why? To avoid license? Linux kernel license requires the kernel not be spreaded with personal modification?
Thanks
I'm setting up my own server and I decide to customize my own kernel.
After make install, a warning message appears on the terminal:
W: Possible missing firmware /lib/firmware/i915/bxt_huc_ver01_8_2893.bin for module i915
I know how to fix it after upgrading the kernel but I want to learn about how to prevent it. I don't know if there is a method can achieve such an effect, please let me know if there is one.
I will be very thankful to you.
Short answer, install or upgrade linux-firmware to get that firmware.
The warning actually comes from mkinitramfs(8) hooks. It looks at the modules to be installed in the initramfs, and checks for all the potentially required firmware files listed by the modules using the MODULE_FIRMWARE() macro in the kernel source, and installs the firmware files in the initramfs alongside the modules. You get the warning if the firmware can't be found.
When the modules installed in the initramfs are probed, there is no rootfs available yet, and you might be missing firmware files required by the modules. Depending on the module and the firmware, there's a risk your newly installed kernel won't work.
If you install the firmware file to rootfs to fix the problem after the kernel install or upgrade, you'll need to run update-initramfs(8) to also copy the firmware to initramfs.
In this specific case, the i915 module would only use that module if you're running on Broxton platform, and even there it's not used by default.
The best option to prevent the warning is to have the firmware available in rootfs (typically under /lib/firmware) at kernel install time. Another option is to exclude the relevant module from initramfs, and probe it later from rootfs instead when it becomes available. Obviously you could also patch the tool to skip the warning, or patch the driver to not list the file using MODULE_FIRMWARE(), but they are hacks better avoided.
I have an (old) embedded system for which I want to compile programs. I don't have the toolchain, so I want to create one.
The embedded system has an "ARM926EJ-S rev 5 (v5l)" CPU and "cat /proc/version" says that it runs "Linux version 2.6.20.7" with GCC 4.0.2.
I have heard that I have to include the kernel headers in the build process. I download the Linux kernel version 2.6.20 from kernel.org, extract all files and run "make headers_install ARCH=arm INSTALL_HDR_PATH=~/headers". Is this the correct way or do I need the header files of the specific kernel?
untar the kernel.
make mrproper
make ARCH=${arch} headers_check
e.g make ARCH=arm headers_check
make ARCH=${CLFS_ARCH} INSTALL_HDR_PATH=dest headers_install
This are the steps to get headers from kernel.
The purpose of kernel headers is -->C library and compiled programs needs to interact with the kernel
i.e for Available system calls and their numbers, Constant definitions, Data structures, etc.
Therefore, compiling the C library requires kernel headers, and many applications also require them.
do I need the header files of the specific kernel?
The kernel-to-userspace ABI is backward compatible
--> 1)Binaries generated with a toolchain using kernel headers older
than the running kernel will work without problem, but won't
be able to use the new system calls, data structures, etc.
-->2)Binaries generated with a toolchain using kernel headers newer
than the running kernel might work on if they don't use the
recent features, otherwise they will break.
--->3)Using the latest kernel headers is not necessary, unless access
to the new kernel features is needed
So in your case kernel version is "Linux version 2.6.20.7"
You can use kernel headers of Linux kernel version 2.6.20 or 2.6.21 from kernel.org.
does not create any problem in this case.
That should be fine if you're using the headers to build a libc
You should probably run make ARCH=arm headers_check beforehand too.
I use CentOS and it does not have support for L2TPv3 which was introduced in 2.6.35.
CentOS is at 2.6.32. How do I selectively patch just the L2TPv3 changes to my kernel?
Also, these are kernel modules. Would I need to run the modified kernel to be able to insmod these KOs?
Back porting features is a very non trivial task, not something that can easily be done casually. Thus, your best option is to look around whether somebody created the necessary patches for your kernel version.
Also, Linux kernel has no strict interface definitions when modules are concerned, thus it is very desirable that kernel and modules are compiled from the same source. Sometimes it is possible to successfully use "mismatched" modules with a given kernel, but rather frequently an attempt to do so results in various problems.
But if you will adventurous, try using modprobe -f. This will disable the module version checking and modprobe will try to squeeze the module in (even at a cost of crashing the system on spot).
how can I obtain runtime information about which version of kernel is running from inside linux kernel module code (kernel mode)?
By convention, Linux kernel module loading mechanism doesn't allow loading modules that were not compiled against the running kernel, so the "running kernel" you are referring to is most likely is already known at kernel module compilation time.
For retrieving the version string constant, older versions require you to include <linux/version.h>, others <linux/utsrelease.h>, and newer ones <generated/utsrelease.h>. If you really want to get more information at run-time, then utsname() function from linux/utsname.h is the most standard run-time interface.
The implementation of the virtual /proc/version procfs node uses utsname()->release.
If you want to condition the code based on kernel version in compile time, you can use a preprocessor block such as:
#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,16)
...
#else
...
#endif
It allows you to compare against major/minor versions.
You can only safely build a module for any one kernel version at a time. This means that asking from a module at runtime is redundant.
You can find this out at build time, by looking at the value of UTS_RELEASE in recent kernels this is in <generated/utsrelease.h> amongst other ways of doing this.
Why can't I build a kernel module for any version?
Because the kernel module API is unstable by design as explained in the kernel tree at: Documentation/stable_api_nonsense.txt. The summary reads:
Executive Summary
-----------------
You think you want a stable kernel interface, but you really do not, and
you don't even know it. What you want is a stable running driver, and
you get that only if your driver is in the main kernel tree. You also
get lots of other good benefits if your driver is in the main kernel
tree, all of which has made Linux into such a strong, stable, and mature
operating system which is the reason you are using it in the first
place.
See also: How to build a Linux kernel module so that it is compatible with all kernel releases?
How to do it at compile time was asked at: Is there a macro definition to check the Linux kernel version?