I'm trying to build a rootfs for an x86 target, which is all simple enough. However I can't figure out how I configure the kernel that buildroot produces. The first run through came up with menuconfig, but it's cached the .config since then and I can't see where to change it.
~650MB of kernel modules don't do good things to an embedded target :P
Is there an easy way to configure the kernel within buildroot? Something like the uclibc-menuconfig target would be perfect.
I always do the following:
configure Linux kernel: make linux-menuconfig
After leaving menuconfig your configuration will be stored in file: output/build/linux-XYZ/.config where XYZ is your kernel version.
After that you can copy file output/build/linux-*XYZ*/.config to board/your_kernel_config/.config
later in Buildroot menuconfig you can under kernel settings configure to use custom kernel config file and enter path: board/your_kernel_config/.config
Do not forget to set also defconfig to i386 in menuconfig:
Kernel —>
[*] Linux Kernel
(i386) Defconfig name
BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES
Adds extra configs to your existing one.
E.g., if you are using buildroot as a submodule, the directory tree looks like:
.git/
buildroot/
.gitmodules
kernel-config-frag
E.g. to turn on CONFIG_DEBUG_FS, do:
echo 'CONFIG_DEBUG_FS=y' > kernel-config-frag
and then configure buildroot with:
cd buildroot
make qemu_x86_64_defconfig
echo 'BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES=../kernel-config-frag' >> buildroot/.config
make
This way you can git track just a diff between qemu_x86_64_defconfig and your extra configs.
I believe this uses scripts/kconfig/merge_config.sh form the kernel as mentioned at: How do you non-interactively turn on features in a Linux kernel .config file?
After you change the config fragment, just remember to do:
rm -rf buildroot/output/build/linux-*.*.*/
before the next build.
Minimal runnable example at: https://github.com/cirosantilli/linux-kernel-module-cheat/blob/bb8f4eb79565c9771356c80e0964c8fefc163e11/kernel-config-frag
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE
Selects the full .config to be used.
For some reason I have to nuke the kernel's .config for this to take effect? Why when I change BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE and run make linux-reconfigure the kernel .config does not change?
And the answer is:
make linux26-menuconfig
The steps are as follows:
cd buildroot/
make menuconfig
Kernel -> Linux Kernel -> Kernel version
Related
I have a Yocto build for i.mx6 and I want to modify its Kernel. I figured that if I copy Kernel source outside the Yocto project and make my modifications without dealing with patches, I can speed things up significantly. But the thing is, the Kernel source I have to use is already patched and I want to fetch and continue working from there. I will work on the already-patched source files and re-arranging them is a painful process.
For starting point, my patches work fine, and I can get a working image using bitbake fsl-image-multimedia-full command. The Kernel source I want to use is created after this process.
I have tried copying the source under ..../tmp/work-shared/imx6qsabresd/kernel-source. Although make zImage and make modules finished without any trouble, manual building was not successful with an error in a dtsi file (Unable to parse...). Of course, I have checked the file and there was no syntax error.
Also, I checked the kernel source files I copied and it seems that the patches are successfully implemented.
Am I doing something wrong with the patches? With my manual build routine, I can build unpatched kernel source with no errors. I am sure that there are experienced Yocto users here that have their own workarounds to make this process shorter. So, any help is appreciated. Thanks in advance.
You can also edit files in tmp/work-shared/<machine>/kernel-source then compile modified kernel with bitbake -C compile virtual/kernel
My favorite method of doing kernel development in a Yocto project is to create an SDK and build the kernel outside of the Yocto system. This allows more rapid builds because make will only build new changes, whereas a kernel build within Yocto always starts from scratch.
Here are some of my notes on compiling the Linux kernel outside of the Yocto system. The exact paths for this will depend on your exact configuration and software versions. In your case, IMAGE_NAME=fsl-image-multimedia-full
Run bitbake -c populate_sdk ${IMAGE_NAME}. You will get a
self-extracting and self-installing shell script.
Run the shell script (for me it was
tmp/deploy/sdk/${NAME}-glibc-i686-${IMAGE_NAME}-cortexa9hf-neon-toolchain-1.0.0.sh),
and agree to the default SDK location (for me it was
usr/local/oecore-i686).
Source the scripts generated by the install script. I use the
following helper script to load the SDK so I don't have to keep
track of the paths involved. You need to source this in each time
you want to use the SDK.
enable_sdk.sh:
#!/bin/bash
if [[ "$0" = "$BASH_SOURCE" ]]
then
echo "Error: you must source this script."
exit 1
fi
source /usr/local/oecore-i686/environment-setup-corei7-32-${NAME}-linux
source /usr/local/oecore-i686/environment-setup-cortexa9hf-neon-${NAME}-linux-gnueabi
Copy the defconfig file from your Yocto directory to your kernel
directory (checked out somewhere outside of the Yocto tree) as
.config.
Run make oldconfig in your kernel directory so that the Linux
kernel build system picks up the existing .config.
Note: you may have to answer questions about config options that
are not set in the .config file.
Note: running make menuconfig will fail when the SDK is enabled,
because the SDK does not have the ncurses libraries set up
correctly. For this command, run it in a new terminal that has not
enabled the SDK so that it uses the local ncurses-dev packages you
have installed.
Run make -jN to build the kernel.
To run the new kernel, copy the zImage and ${NAME}.dtb files to
your NFS/TFTP share or boot device. I use another script to speed
up the process.
update_kernel.sh:
#!/bin/bash
set -x
sudo cp /path-to-linux-source/arch/arm/boot/dts/${NAME}.dtb /srv/nfs/${DEVICE}/boot/
sudo cp /path-to-linux-source/arch/arm/boot/zImage /srv/nfs/${DEVICE}/boot/
set +x
You can also point Yocto to your local Linux repo in your .bb
file. This is useful for making sure your kernel changes still
build correctly within Yocto.
SRC_URI = "git:///path-to-linux-source/.git/;branch=${KBRANCH};protocol=file"
UPDATE: Over a year later, I realize that I completely missed the question about broken patches. Without more information, I can't be sure what went wrong copying the kernel source from Yocto to an external build. I'd suggest opening a Bitbake devshell for the kernel and doing a diff with the external directory after manually applying patches to see what went wrong, or just copy the source from inside the devshell to your external directory.
https://www.yoctoproject.org/docs/1.4.2/dev-manual/dev-manual.html#platdev-appdev-devshell
When debugging certain commands or even when just editing packages, devshell can be a useful tool. When you invoke devshell, source files are extracted into your working directory and patches are applied.
Since it can't parse it, there seems to be a problem with patch. How do you patch the device tree? Are you patching it in the .bb file?
If so, check your patch for possible syntax errors, it's very easy to overlook the syntax errors in device tree. You can remove the patch and do it manually from bitbake -c devshell <kernel-name>
If not, please try to do it there and check again. Please share results if any of these helps you.
I have recently git cloned the kernel of Linus Torvalds. I want to build and install this kernel in my laptop. But because I want to use "kernel-of-the-day" I want to enable CONFIGURE_LOCALVERSION_AUTO option. But how should I enable this option I don't know that. Where to find this option?
Use menuconfig or xconfig, to configure Linux kernel these interfaces are used. Modifying .config file directly is discouraged. Inside your kernel source tree do make menuconfig or make xconfig - use anyone you like. On kernel configuration menu you'll find General Setup Option, inside this option you'll find Automatically append version information to the version string, toggle it to enable/disable.
After you have cloned the Linus repository repository. You would need to either create a fresh .config file in the ./linux folder or copy the existing config file from your /boot and later modify it. Then edit the .config file and set CONFIG_LOCALVERSION_AUTO=y
`cp /boot/config-`uname -r` .config`
I want to add some debug info or printf in the random.c in order to look deeply into the Linux random number generator. The entropy in /dev/random and /dev/urandom are both generated by random.c. My questions are:
1. Where I can find the random.c file in Linux 2.6.32?
2. What is the best way to add my modification of random source code into the kernel? Is it OK to just compile random.c and load it as loadable kernel module? Or do I have to recompile and install the kernel to make the new random.c with debug msg somehow take effect? The key point is to make sure that only one copy of random number generator is running in the kernel.
Thank you. Any kind of suggestion is highly appreciated.
random.c is linked directly into the kernel, it isn't built as a module, so you can't just recompile it alone and load it into your kernel, you need to recompile the whole new kernel.
To build the kernel, make sure you have the usual development tools installed: gcc, GNU make, etc. Some distros provide a "build-essentials" or "Development Tools" or similar metapackage that include all of the usual development tools for building the core system packages.
How you build your kernel depends on whether you have any distribution specific patches that are needed to use your system, or if you want to ensure that you use your distro's packaging system to install the kernel. If so, you should probably follow your distro's instructions for building the kernel. For example, Ubuntu's instructions, Arch's instructioins, Fedora's instructions, CentOS instructions (likely similar on RHEL 6, Red Hat doesn't provide documentation as they don't support building custom kernels), SuSE instructions.
Otherwise, if you don't mind configuring and installing your kernel manually, you can do it by hand. The following instructions should cover most distros reasonable well, but be sure to check your distro docs in case there are any distro-specific gotchas.
Download the appropriate tarball from kernel.org and decompress it somewhere. Or if you prefer, check it out using Git. Since you reference 2.6.32, I've included the latest version of 2.6.32 in the below instructions.
$ curl -O https://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/linux-2.6.32.61.tar.xz
$ xzcat linux-2.6.32.61.tar.xz | tar xvf -
$ cd linux-2.6.32.61
# or...
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
$ cd linux
$ git checkout -b my-branch v2.6.32.61
Now you need to do to configure it, build it, and install it. Greg Kroah-Hartmann, a leading kernel developer and stable kernel maintainer, has a free book on the subject. I'd recommend reading his book, but if you want a quick rundown, I'll summarize the highlights.
There are several ways to configure it. A good way to start is to just copy your current config in, and then run make menuconfig or make xcconfig to get a curses or graphical kernel configuration utility that allows you to easily browse and choose the right options (as there may be new options in the new kernel that you are building). Many distros install the config for a given kernel in /boot/config or /boot/config-version corresponding to the kernel version. Copy that into your source tree as .config, and then run make menuconfig or make xconfig:
$ cp /boot/config .config
$ make xconfig
After configuring it, I'd recommend adding something to the EXTRAVERSION definition in the Makefile. The contents of that are tacked on to the version, to help distinguish your modified kernel from the upstream one. I'd recommend setting it to help keep track of which is your modified kernel.
Once it's configured, just build it like anything else. I recommend using -j to run a parallel build if you have multiple cores.
$ make -j8
Now it's built, and you can install it. On most systems, the following works; if not, check out Greg's book or check your distro's documentation:
$ sudo make modules_install
$ sudo make install
And finally you have to add it to your bootloader (on some systems, make install may do this, on some it may not). Depending on whether you use Lilo, Grub, or Grub2, you may need to edit /etc/lilo.conf (followed by running sudo lilo to install the changes), /boot/grub/menu.lst, or /boot/grub/custom.cfg (followed by sudo grub-mkconfig -o /boot/grub/grub.cfg to install the changes). See the relevant documentation for the given bootloader for more details. Generally you want to copy an existing entry and duplicate it, updating it to point to your new kernel. Make sure you leave the existing entries, so you will be able to boot back into your old kernel if this doesn't work.
Now reboot, select your new kernel, and hope your system boots. Woo! You've built your own kernel.
Now that you've made sure you can do that successfully without modifications, you can make your change. You are going to want to modify drivers/char/random.c. To print out debugging statements, use printk(). It works mostly like printf(), though it's not exactly the same so check out the documentation before using it. After you modify, rebuild, and reinstall your new kernel, and reboot into it, you can see the messages printed out with printk() statements using the dmesg command.
For more information, check out Greg's book that I linked to above, the kernel README, and HOWTO, browse around the kernel's Documentation directory, and various other docs.
If you look at the Makefile for it, char driver is not meant to be compiled as a module (random.o is included as obj-y in drivers/char/Makefile).
You can read more about how to kbuild (kernel build) system works from: https://www.kernel.org/doc/Documentation/kbuild/makefiles.txt
Particularly section --- 3.1 Goal definitions touches this topic.
Generally you can search for files in kernel sources from source cross references (called LXR's). One is for example provided in http://lxr.free-electrons.com/
Indeed, you can add your modifications to the drivers/char/random.c, and recompile the char driver. After that you will have to rebuild the kernel, so that it will link also your new random.o to the kernel. And then you will have to boot that kernel, that process will depend on your distribution.
Most distributions have good/decent instructions around how to recompile/boot your own kernel.
I am going to setup build environment to make my own linux embedded system for AT91SAM9X25 Board. I am using buildroot to do this. The make command build all targets, the first it build toolchain then packages and then rootfs and images of rootfs (tar, cpio ...).
To rebuild rootfs I usually use make clean and then make. The make clean command removes all and including toolchain.
So the first my question is: Is there some way to remake rootfs without building toolchain? It takes a lot of time.
Also I am building linux kernel within buildroot. I have turned on BR2_LINUX_KERNEL [=y] in buildroot. The linux configured to use Initial RAM filesystem, so to build kernel it required image of rootfs (which should be created by buildroot). When I run make under root of buildroot the building fails with error Cannot open 'buildroot-2013.05/output/images/rootfs.cpio'. Because (if I understand correctly) the building sequence is toolchain - pakages - rootfs - linux kernel - images of rootfs. When it tries to build linux kernel the rootfs.cpio image is not created.
So the second question is: How to build linux within buildroot if I want to use Initial RAM filesystem?
Possibly are there more efficient alternatives than buildroot?
Thanks in advance.
The make command build all targets
You do not want to do that (until Buildroot is configured).
You first need to configure Buildroot by specifying the target board.
Per the manual you can start from scratch, or create a Buildroot config file for your AT91SAM9X25 board derived from a similar board such as configs/at91sam9g20dfc_defconfig
Besides the Buildroot config file, you will also need a Linux kernel config file (unless you want to try configuring the kernel from scratch).
The kernel config file for Atmel's eval board with a AT91SAM9x5 is at91sam9x5ek_defconfig
You should also read section 3.4.2. Creating your own board support
So the first my question is: Is there some way to remake rootfs without building toolchain? It takes a lot of time.
The answer depends on how you define "remake rootfs".
If you delete the directory output/images/, then the files of the rootfs are rewritten.
If you delete directories in output/build/, then those packages or subsystems are recompiled from source.
If you configure Buildroot to use your own or an external tool chain, then make clean would not remove them. If you configure Buildroot to install the toolchain it builds outside of its directory, then it may leave it alone during a make clean.
Of course the Buildroot make is smart enough to know what has changed since the last build and what has to be recompiled.
It should be the rare case that you need to delete directories in output/build/ to force recompilation.
So the second question is: How to build linux within buildroot if I want to use Initial RAM filesystem?
You need to properly configure both Buildroot and the Linux kernel.
make menuconfig
Filesystem images --->
make linux-menuconfig
General setup --->
make
More concise information on using Buildroot for AT91SAM9x5 is this Linx4SAM page
Possibly are there more efficient alternatives than buildroot?
There are other tools such as Open Embedded, but describing them as "more efficient" is subjective.
ADDENDUM
how to rebuild rootfs in buildroot
To force the rootfs to be rebuilt (in this case an initramfs) delete three hidden files in the output/build/linux-x.xx.xx directory
.stamp_images_installed
.stamp_initramfs_rebuilt
.stamp_target_installed
Rebuild rootfs in buildroot
View dependencies:
make show-targets
Example output:
rootfs-cpio rootfs-tar rootfs-ubi rootfs-ubifs
Rebuild the target. Example:
# Tell buildroot to rebuild `rootfs-ubi`
make rootfs-ubi rebuild
If you only want to regenerate the rootfs partition, do
rm -r output/target && make
This helps, e.g., if you removed files in a rootfs overlay.
I tried using make defconfig to compile the kernel, but as expected, it failed to boot. I was wondering what .config file do kernel vendors like Canonical for Ubuntu use, that the kernel is able to boot right out-of-the-box. Of course, I am still a beginner and configuring the various parameters, is a little out of my league currently.
Specifically,I am looking to load a basic "hello, world!" module to my running kernel 2.6.32.41. For that, I would need to compile kernels source against the same .config file that was used for the running kernel.
If your running kernel was compiled with the CONFIG_IKCONFIG_PROC option, you can get the config in /proc/config.gz:
$ zcat /proc/config.gz >my_config
Copy my_config into your kernel build directory as .config and run make config to be prompted for configuration options that are absent from your config file (this will only happen if you are using a kernel source that is newer than your running kernel). You should then be able to compile a new kernel with the same features as your current one.
Distros typically use their own kernel configuration, where most of the drivers are compiled as modules to be dynamically loaded when the corresponding hardware is requested. Also the kernel needs to be booted with relevant boot options (like the one specifying the root filesystem). Your defconfig kernel probably failed to boot because of that.
I don't know about getting the one that's "correct for your hardware", but you can use the config that Ubuntu gives you by looking in /boot/ for a file starting with the name config. There may be more than one, in which case use the command uname -r to tell which kernel you're currently running, and then you can use the appropriate config.
option1:
source code of your booted system
cd /usr/src/linux-headers-3.2.0-29;
this will generate .config
sudo make oldconfig;
vi .config
option2:
zcat /proc/config.gz > my_config
option3:
echo /boot/config* > my_config
"defconfig" is usually pegged at the commonly used hardware - x86, or x86_64, and perhaps not so recent chipset or motherboard. Sometimes, like my Lenovo laptop, only the latest kernel source, and with enabling some config option, after googling through the bugzilla database, will it work.
Like what Jeff Welling said, to get the config in use, u can look under /boot directory. Same for my Fedora Core too. But if u want to compile a basic program as a "kernel module", and by that it simply means "loadable kernel module", u don't need to compile the kernel source. U just need the kernel headers for that current version. For example, "apt-cache search" in Ubuntu 10.04 returns several possible option:
linux-headers-2.6.38 - Header files related to Linux kernel, specifically,
linux-libc-dev - Linux Kernel Headers for development
Ubuntu normally patched the stock kernel (from kernel.org) to have their own kernel. If u have downloaded the stock kernel, and attempt to use the /boot's config file (or sometimes u can find the currently loaded config as /proc/config.gz, like the Backtrack's Ubuntu, which is based on 10.04 LTS), then u may need to do a "make oldconfig" with the current config file named as ".config". "make oldconfig" will then use the .config to generate a new .config that is compatible with the kernel source.