So, each time I modify the device tree I typically change the dts in a custom recipe and rebuild the image. The rebuild takes a long time since it rebuilds the entire kernel, and then the image needs to be built and finally deployed to the target device.
Is there any trick that I'm missing that rebuilds only the device tree?
UPDATE:
I've marked g0hl1n's answer as the correct one, since it is the answer to my question. However, I found it to be very cumbersome to work with the kernel in Yocto: strange, long paths and risk of files being overwritten on each rebuild, source of kernel in tmp/work-shared while the kernel is being built in tmp/work.
Instead I've moved the kernel development out of Yocto. Yocto has good tools for creating an SDK (see populate_sdk task) and with that it's easy to setup an environment for kernel development with quick rebuilds and manual (or scripted) deployments. Once the work is done the changes can be moved to a recipe using git diff.
The instructions on the following page was very helpful: http://jumpnowtek.com/beaglebone/Working-on-the-BeagleBone-kernel.html
AFAIK there are two different ways of doing this.
The kernel way: Using the scripts provided by the kernel
Change to your kernel source directory (<build dir>/tmp/work/<machine>/<kernel-name>/<kernel-version>/git/)
Execute the device-tree-compiler: ./scripts/dtc/dtc -I dts -O dtb -o ./devicetree.dtb path/to/devicetree.dts
The bitbake way: Using the kernel's deploy job
Call $ bitbake <kernel-name> -f -c deploy
The generated device-tree-blob then can be found in <build dir>/tmp/work/<machine>/<kernel-name>/<kernel-version>/build/arch/arm/boot/dts/)
At least for me both versions worked in a quick test.
UPDATE:
I just came over a third version of building the dtb with yocto on the net.
That one uses yocto's devshell of the kernel build.
For more information see the original authors page at https://splefty.blogspot.co.at/2015/09/compiling-device-tree-using-yocto.html.
For me using bitbake to regenerate the device tree worked in the following way:
Command: $ bitbake <kernel-name> -f -c compile
Example: $ bitbake linux-fslc -f -c compile
Tested using yocto sumo.
Related
I work for a large yocto based project which builds has a target that builds the firmware for an embedded ARM device.
One of the recipes downloads the source code and builds a component by running a "make " command in do_compile(). The compilation will use the arm toolchain internally and produce an executable for the ARM arch.
For that specific component a different "make <host_tool>" target can build a host tool that is useful when debugging binary logs obtained from the target.
The objective here is to build the "host_tool" during the bitbake process. I am not sure who should the recipy file look in such a case. Should the "MACHINE" variable be overwritten locally in that recipy file ? Should I create a completely new layer when there MACHINE for that recipy be included there ? Should I create a completely new "bitbake " target ? If the latter is the correct approach where should I place my recipy in that case ?
Thank you in advance for your help
How can I build a Linux kernel in Travis CI. I have added script: make menuconfig to my Travis config and it doesn't work and says
No output has been received in the last 10 minutes
How can I fix this?
Link to GitHub repo : https://github.com/ProjectPolyester/tegra_kernel and submit fixes in PRs if possible
Travis monitors your build process and if there is no output for about 10 minutes, it assumes that your process is stuck somewhere for unknown reasons, and then kills it.
Solution in your case :
You need to provide with the actual build command.
make menuconfig
actually just allows you to configure the kernel. It doesn't really starts the kernel build process. So there is no output of this command.
Also, the kernel should already be configured or you can download the appropriate .config file if its available some where online. And then there will be no need to execute:
make menuconfig
The build command
It can be simply
make
or something like
make -j3 modules ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LOCALVERSION=-$SOURCE_VERSION
The second one is actually to perform cross compilation.
You also need to set all the prerequisites like downloading the header file etc
You may want to take a look at this script , it crosscompiles the modules only, not the entire kernel.
If you want to use the old config for a new kernel, you can use make olddefconfig. Here is my example how to compile and boot a new kernel in travis: https://github.com/avagin/criu/blob/linux-next/scripts/travis/kexec.sh#L54
I know that this is an old thread but I was recently able to get Travis CI working on building a Linux kernel
https://github.com/GlassROM-devices/android_kernel_oneplus_msm8994/commit/6ed484812bbd4a25c3b22e730b7489eaaf668da1
GCC fix is for toolchains compiled on Debian unstable, arch, gentoo, etc. These toolchains will fail to compile on Ubuntu so you'll have to use the GCC fix for these toolchains
And you really want to upgrade GCC before you even try building a kernel. Travis CI has a very old GCC that will fail if you try to compile the kernel
In my commit I'm building it with GCC 8 linaro built by myself
Is there any way to cross compile gcc and gdb using the bitbake command in YOCTO project?
If I get you correctly you want to add gcc and gdb to the image.
The easiest and cleanest solution I know is to enable them via EXTRA_IMAGE_FEATURES.
Typically, you configure this variable in your local.conf file, which is found in the Build Directory. Although you can use this variable from within a recipe, best practices dictate that you do not. [1]
EXTRA_IMAGE_FEATURES = "tools-sdk tools-debug"
[1] http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-EXTRA_IMAGE_FEATURES
To create the image-based SDK, For example, run this:
$ bitbake core-image-full-cmdline -c populate_sdk
With that, the SDK is created based on the core-image-full-cmdline image.
After it is done, the binary script can be found at /build/tmp/deploy/sdk/poky-eglibc-x86_64-core-image-full-cmdline-armv5te-toolchain-1.6.sh
To create generic SDK, use meta-toolchain
$ bitbake meta-toolchain
Find how to set up Qt here
I have compiled my kernel(linux-3.6.6) with success in the debian linux version(12.04).(LinuxPraxis ->is the name of my new version) then I made some modification on Read_write.c file ("I mind I write there some printk to get a message when a named pipe is writting and when it is reading").
Now I hear that I need to recompile my new version. please help me to understand it.
Shall I need to recompile my kernel completely or it is another way to recompile a kernel?
Use "make -j5" to rebuild your kernel image file for host system with 4 cores.
Then run "make install -j5" to install kernel image file.
The "make install" will compress your kernel image file, copy kernel image to /boot and run grub-update to update the grub config file.
If you have already compiled, the Makefile takes care of only recompiling the parts which depend on the changed file(s). There could still be multiple files which depend on it, but the effort should be significantly smaller than the initial compilation nevertheless. You don't have to do anything differently, the compilation works the same; files which already exist on disk which do not depend on the changed file will simply not be recompiled.
I am trying to compile a driver that we have from source and I am working through the issues with a new target environment. One of the slightly disturbing things I see is the following warning:
WARNING: Symbol version dump /usr/src/linux-2.6.38/Module.symvers
is missing; modules will have no dependencies and modversions.
I spent a fair amount of time looking on the web and this is shown in output frequently when other questions are asked, but I didn't see any commentary about whether or not this is an issue.
In any case, how would I tell linux/ubuntu to generate Module.symvers?
Module.symvers is generated when the kernel itself is compiled and ought to be provided to the user as part of the kernel build environment package, however that may look on Ubuntu (possibly broken there?) Fedora and openSUSE for example ship one or more “kernel-devel” (and/or similarly-named) packages that ship this build environment and make the file reachable through /lib/modules/<version>/build/Module.symvers. When using a self-compiled kernel, substitue /lib/modules/version/build for the appropriate path to the build directory (where all the .o files are).