In LinuxSrc/Documentation/admin-guide/README.rst under the section for building the kernel exists these 4 steps, can someone explain what each one does?
Is it similiar to a ./configure, ./make, ./install?
To configure and build the kernel, use:
1.) cd /usr/src/linux-4.X
2.) make O=/home/name/build/kernel menuconfig
3.) make O=/home/name/build/kernel
4.) sudo make O=/home/name/build/kernel modules_install install
1) simple cd - no explanation needed
2) Running make menuconfig starts an ncurses-based text mode kernel configuration tool.
3) make O=/home/name/build/kernel configures and builds the kernel.
4.1) modules_install: This will copy the compiled modules into /lib/modules/-.
4.2) install: This command will copy following files into /boot directory (and might do more depending on the distribution):
Config-, System.map-, Vmlinuz-*
vmlinuz - Is a compressed Linux kernel
system.map - Is a lookup table between symbol names and their addresses in memory for a particular build of a kernel
config - The kernel configuration created by the make menuconfig
Related
I want to add entries to a vendor-provided defconfig for a Yocto distribution. In order to add the new drivers I want, I usually use the following process in my Linux directory:
$ cp $YOCTO_MYKERNEL/files/defconfig .config
$ make menuconfig
$ # I select some drivers I want to add and save .config file
$ make savedefconfig
$ cp defconfig $YOCTO_MYKERNEL/files/defconfig
The savedefconfig step adds my drivers correctly, but is also removing some important drivers that are vendor-provided:
$ diff -u $YOCTO_MYKERNEL/files/defconfig defconfig
--- $YOCTO_MYKERNEL/files/defconfig
+++ defconfig
## -1,22 +1,11 ##
-CONFIG_FHANDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_CGROUPS=y
CONFIG_BLK_DEV_INITRD=y
-CONFIG_PERF_EVENTS=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
-CONFIG_ARCH_SUNXI=y
CONFIG_SMP=y
CONFIG_NR_CPUS=8
-CONFIG_AEABI=y
-CONFIG_HIGHMEM=y
-CONFIG_ARM_APPENDED_DTB=y
-CONFIG_ARM_ATAG_DTB_COMPAT=y
-CONFIG_CPU_FREQ=y
-CONFIG_CPUFREQ_DT=y
-CONFIG_VFP=y
-CONFIG_NEON=y
[...]
If I understood the savedefconfig step well, it is removing options that are already set by default and thus redundant. However removing all these vendor-provided drivers are causing the newly compiled kernel to not boot at all after uboot.
I even tried only the savedefconfig step without adding any drivers, and vendor drivers are removed and kernel hangs.
Do you have any idea why savedefconfig is removing these entries, and how to make it stop? Currently I have to isolate diff changes by hand and manually add new lines that I am interested in into the Yocto defconfig file.
I have found the reason for all of this: I was calling make savedefconfig without specifying the ARM architecture, thus I think the build system will remove any non-revevant entries like all the SUNXI_* drivers (because they are not used on x86_64).
This call does not mangles important drivers:
make ARCH=arm savedefconfig
In order to not forget to do this step, one can use the Yocto steps instead that will automatically use the relevant architecture:
bitbake -c menuconfig virtual/kernel
bitbake -c savedefconfig virtual/kernel
Bitbake will print the path of the generated defconfig file that you will have to copy over the older one in order to take the changes into account.
I am following the guide https://wiki.eclipse.org/HowTo_use_the_CDT_to_navigate_Linux_kernel_source
In step 2 (above link):
Configure and build your kernel to define CONFIG_* and generate autoconf.h. This can be done before or after downloading and installing Eclipse.
Can someone explain what step 2 is referring to? Would it be related to step B below?
This is my current process of compiling the kernel:
a.) make O=/home/name/build/kernel menuconfig
b.) make O=/home/name/build/kernel
1). make O=/home/name/build/kernel menuconfig
Generate .config (configure linux to generate .config)
2). make O=/home/name/build/kernel
To compile kernel code
I am currently working on linux kernel 3.11.0-12. But I am adding a system call by modifying the source code I downloaded from kernel.org of linux-2.6.26. I want to compile the modified 2.6.26 kernel to test my new system call. How should i do it?
1)If you want to build kernel for same architecture on which you are working then..
go into your linux source folder and fire below commands....
To Clean:
make distclean
To write config:
make defconfig
To build Kernel:
make uImage
or make vmlinux which image you want to build
2)for arm architecture...
To Clean:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- distclean
To write config:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- defconfig
To build Kernel:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- uImage
3) using second step you can build linux kernel for any platform with any toolchain
just use ARCH= CROSS_COMPILE= macro as per requirement......
I assume you use a vanilla kernel and that you are working on a module. Vanilla or not, you need the configuration file for the target kernel.
Just download the source, copy the kernel configuration file to <kernel_source>/.config and build the kernel once, since you need the configuration- and header-files for an out of kernel source build. Use make modules_prepare.
Then run make -C <full_path_to_kernel_source> M=$PWD to build the module.
Take a look at here for more detailed information.
I'm trying to cross compile the FTDI VCP Driver for my embedded arch linux arm machine. I downloaded the source files from http://www.ftdichip.com/Drivers/VCP.htm onto my host machine which is running kernel:
2.6.32-54-generic-pae
When running the Makefile, I get errors related to kernel headers, ie: asm/thread_info.h file not found. I realize that this means that my asm symlink is broken, so I tried linking it to
linux-headers-2.6.32-54/include/asm-generic
but the contents of that directory does not include thread_info.h either, which I'm trying to find.
Has anyone cross compiled the FTDI VCP Driver for embedded arch linux arm using Ubuntu as their host and can point me in the right direction? I'm new to building kernel modules and cross compiling and any help would be appreciated.
If anyone requires more information I'd be more than happy to add it.
make ARCH=arm menuconfig
Make and install modules: make modules and make modules_install
Don't forget: insmod usbserial.ko and insmod ftdi_sio.ko if you need to, and depmod -a to have them load after a power cycle.
Don't forget to include your cross compiling chains.
Basically u need cross-compile kernel in host x86 machine.
First check the source code is already configured and built if so.
make ARCH=arm menuconfig
window ll appear and enable ftdi in driver .
if source code is clean.
then u need to copy /proc/config.gz file from target machine to host and untar it.
copy to source top folder like `cp config .config'
make ARCH=arm menuconfig
and enable your driver
After this make ARCH=arm CROSS_COMPILE=<your tool chain> zImage
e.g make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- zImage
make ARCH=arm CROSS_COMPILE=<your tool chain> modules
e.g make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- modules
The FTDI "VCP" driver has been a part of the linux kernel for a good while now. You don't need to download anything, except for the kernel itself. As long as you can cross-compile your kernel, you're all set.
I am cross-compiling 3.4.0 kernel for an embedded device. Then I would like to install compat-wireless drivers which require /lib/modules/3.4/build directory and sub-files. Could anyone explain how can I build that directory so that when I do INSTALL_MOD_PATH=newmodules make modules_install it would load /lib/modules/$(uname -r)/build directory as well? I would appreciate for a clear explanation.
I am using debian distro. I know I can install the kernel headers by apt-get install linux-headers-$(uname -r), but I doubt it would be a good idea since the kernel sources might not be identical.
Typically /lib/modules/$(uname -r)/build is a soft-link to the directory where performed the build. So the way to do this is to simply do a
make modules_install INSTALL_MOD_PATH=/some/root/
in the build directory of the kernel where /some/root is where you want your cross compile pieces to end up. This will create a link to your kernel build path in /some/root/lib/modules/$(uname -r) ... verify that.
Now when you build the compat_wireless drivers specify the kernel build directory in the Makefile as /some/root using the KLIB_BUILD variable (read the Makefile)
make modules KLIB_BUILD=/some/root/lib/modules/$(uname -r)/build
this should do the trick for you.
EDIT A
In answer to your comment below:
Keep "newmodules" outside the kernel directory it's a bad idea to put it in the kernel directory. so mkdir newmodules somewhere like /home/foo or /tmp or something. This is one of the reasons your build link is screwed up
ALSO .../build is a soft link /to/kernel/build/location it will only copy over as a soft-link. You also need to copy over the actual kernel source / kernel build directory to your microSD, using the same relative location. For example,
Let's say your kernel source is in:
/usr/src/linux-3.5.0/
Your kernel build directory is:
/usr/src/linux-3.5.0-build/
Your newmodules (after following 1.) is in:
/tmp/newmodules/
So under /tmp/newmodules/ you see the modules installed in a tree like:
lib/modules/$(uname -r)/
when you do an ls -al in this directory, you'll see that build is a soft link to:
build -> /usr/src/linux-3.5.0-build/
Now let's say your microSD is mounted under /mnt/microSD
then you need to do the following
mkdir -p /mnt/microSD/usr/src
cp -a /usr/src/linux-3.5.0 /usr/src/linux-3.5.0-build /mnt/microSD/usr/src
cp -a /tmp/newmodules/lib /mnt/microSD/lib
Now you have all the content you need to bring over to your embedded environment. I take it you are doing the compat_wireless build on your target system rather than cross compiling it?
NOTE
If your kernel build is the same as the kernel source then just copy over the kernel source and ignore the linux-3.5.0-build in copy instructions above
This is old, but some people will need this information.
I have spent many hours to figure out where build folder comes from, and why it is just a link when I compile my own kernel. Finally figured it out;
Linux kernel usually just links the build and source folders to the source folder.
But!
Arch linux (probably some other distros too); has a manual script for deleting those links, and adding (filtered) files to build folder.
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux
I've extracted that script to work standalone (in a kernel source tree) here: https://gist.github.com/furkanmustafa/9e73feb64b0b18942047fd7b7e2fd53e