Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
wiki:custom_kernel [2012/03/13 08:15] – Title added bernhard | wiki:custom_kernel [2022/09/21 17:10] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | === Creating a Custom Kernel === | ||
+ | Some users of TC will for various reasons need to use their own custom built kernel together with the rest of TC. As an example my main use of TC is in music production and in that domain a lot of the applications are performing optimal only with the support of a kernel that provides real-time characteristics. Since the standard TC kernel does not provide these characteristics I need to build a kernel that does. Luckily, there is a set of patches available, that once applied (and built) will provide you with a suitable kernel for these music production tasks. I do not intend to go into the details of " | ||
+ | |||
+ | In general the standard TC kernel is a fairly standard Linux kernel, meaning that is has just a few set of patches applied. In general I think that TC will work with a kernel without patches, i.e. a " | ||
+ | |||
+ | Standard Linux kernel sources are available at | ||
+ | |||
+ | https:// | ||
+ | |||
+ | The TC patches and other related files for the standard TC kernel are available at | ||
+ | | ||
+ | http:// | ||
+ | |||
+ | The process to create a custom kernel could in short be described as: | ||
+ | |||
+ | - Get the sources for the version of the standard Linux kernel that you are going to base your kernel on | ||
+ | - Get the patches you intend to apply - both TC kernel patches and possibly others (in my case the RT-patches) | ||
+ | - Unpack the linux sources and cd into the top level directory of the source package | ||
+ | - Apply the patches using (in most cases) "patch -p1 < patchfile" | ||
+ | - NOTE: "patch -p1 < patchfile" | ||
+ | - Move the kernel config file from the standard TC kernel into the same directory and rename it to " | ||
+ | - Do "make oldconfig" | ||
+ | - Do "make menuconfig" | ||
+ | - Do "make bzImage" | ||
+ | - Do "make modules" | ||
+ | - Do "make INSTALL_MOD_PATH=/ | ||
+ | |||
+ | |||
+ | At this point you will find the kernel file as " | ||
+ | Further you will find all loadable modules and firmware files under "/ | ||
+ | |||
+ | The bzImage file need to be moved to a location where your boot loader can access it and the boot loader needs also to be configured to boot using the new kernel. | ||
+ | |||
+ | When it comes to the modules and firmware files, you basically have two options, either let them be part of your initrd (a file named " | ||
+ | |||
+ | IMPORTANT. If you are using a custom kernel you should never use any *.tcem files from standard TC. You could probably load them and they will likely not produce any harm, but taking up memory space, but they will not provide the function you expected. As you can notice above the modules are placed under a directory that contains the current kernel version and the modprobe program will only load modules from the directory that matches the version of the current kernel. | ||
+ | |||
+ | |||
+ | The standard TC initrd and the standard *.tcem packages are structured as follows to allow dynamic loading of module extensions: | ||
+ | |||
+ | The module files in the *.tcem, when installed, are found as | ||
+ | |||
+ | / | ||
+ | |||
+ | In order fro them to be visible under | ||
+ | |||
+ | / | ||
+ | |||
+ | the initrd contains a link called " | ||
+ | |||
+ | As you probably could imagine, the standard initrd has no knowledge of your kernel version, so you have to create this link in your initrd explicitly. | ||
+ | |||
+ | Remember that the standard TC *.tcem files could only be used with the standard TC kernel so this " | ||
+ | |||
+ | ==== !Links ==== | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[http:// |