I am trying to build a buildroot with kernel image, and after doing make menuconfig and make, I am getting:
No kernel defconfig name specified, check your BR2_LINUX_KERNEL_DEFCONFIG setting
I can set a string to the defconfig, but I don't know what to put there.
My target system is an AT91SAM9RL board.
edit: I found out there are some pre-made config files to some devices, actually not exactly matching to my target.
You can issue the default configuration process by running make xxx_defconfig and that make target is a file in the folder arch/arm/configs/. These default configurations are not designed to exactly fit your target, but are rather meant to be a superset so you only have to modify them a bit.
The make xxx_defconfig creates your initial .config, which you can now edit through make menuconfig and make your changes. After that, you can run make which will then compile the kernel using your settings.
Related
So I use defconfig files to keep the kernel settings/configuration for an embedded project.
Whenever I do changes to the actual config through means like make menuconfig and then do a make savedefconfig afterwards the resulting defconfig file looks completely different to the preexisting one. The order of contained config options seems random at least or following some order not obviously understandable.
Problem about this for me the defconfig files are not diff-able anymore.
To work around this I want to sort the defconfig file before checking it in.
This way I can perfectly track any changes using any diff-tool.
Question is:
Is there any inherent order necessary in defconfig files for the linux kernel. Will this mess with the kernel build system in any way?
If you want to modify the linux kernel such that it excludes certain modules, you usually go to /kernel/msm-4.9/arch/arm/configs/vendor/<machine-name>_defconfig, which has a bunch of Kconfig symbols, and the ones I want to exclude are commented out, as shown below.
CONFIG_PPP=y
#CONFIG_PPPOL2TP=y
CONFIG_PPP_ASYNC=y
Then I build the linux image by running bitbake virtual/kernel which should ideally have my changes integrated, but when I boot the image, I still see some of the logs of the commented module showing up.
I checked yocto documentation and looks like they create a patch of the file they want to modify, and then append that modified file in the .bbappend file like:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://0001-calibrate-Add-printk-example.patch"
So in my case, if I were to modify /kernel/msm-4.9/arch/arm/configs/vendor/<machine-name>_defconfig, I would:
create a copy of this original file
paste it into poky/meta-bsp/recipes-kernel/linux-msm/files
rename it
include this file in the .bbappend (as shown above)
But how will the above patch override the original /kernel/msm-4.9/arch/arm/configs/vendor/<machine-name>_defconfig that I planned on modifying by this approach?
You are right, sources modifications are done with help of patches in Yocto. Answering your question
But how will the above patch override the original /kernel/msm-4.9/arch/arm/configs/vendor/_defconfig that I planned on modifying by this approach?
it is done automagically:)
That is, build system (bitbake) automatically detects files with extension .patch among SRC_URI content, copies those files from meta-layer directory to build directory somewhere under build/tmp/work/... and automatically applies thous patches on source code (sources directory is defined by S variable in recipe).
But there are some recommendations about other stuff in your question. Some concepts here, skip it to the right way is or even fast way below if bored))
One of the main ideas behind Yocto is reproducible and extensible builds. That means, that all metadata is split into different repositories (that is layers), that are maintained by different teams. Basically teams do not have access to each others repos and none has access to some external project (kernel in your case) source code. Of cource, one may create git-forks of all this, but this is way more complicated than writing metadata. That's why Yocto was created - to take external metadata (ex., poky layer), source code ('kernel') and make it work only by writing your one metadata (your own layer), with no any git-forks.
So, adding your patch and .bbappend to poky layer make no sense, because you wouldn't be able to commit poky layer and distribute this to your customers - poky layer belongs not to you) You may create git-fork however, but that complicates the process of distribution.
That's why the right way is:
create your own BSP-layer
create .bbappend in your layer
add patch to the kernel in your layer (actually the right way is to use .scc files, put patch also will go)
This shall make your build
reproducible - rerunning kernel compilation, or even fresh clone of Yocto with your BSP-layer, would be able to produce the same kernel
distributable (extensible) - customers need only your BSP-layer, other Yocto stuff may be found on internet
And finally, the fast way. If you don't need all this reproducible and extensible but just build some stuff for your home-project and send Yocto to trash, hack the build like this:
clean all kernel-stuff you have bitbake -c cleansstate virtual/kernel
get kernel sources (clone and patch) bitbake -c patch virtual/kernel
handle manually everything you need in kernel sources, found somewhere on working stuff like <TOPDIR>/build/tmp/work/<machine-name>-poky-linux-gnueabi/linux-yocto/<version>/git
build the kernel bitbake -c package virtual/kernel (cloning and patching would be skipped, as bitbake remembers this tasks are done; kernel build artifacts wouldn't be removed, because task rm_work goes after package, and kernel stuff actually is never removed)
But in this case, if this kernel stuff is removed, or breaks somehow, you'll have to walk through this algorithm again (remember - not reproducible).
To easy rebuild the kernel manually (not through bitbake) you can run script <TOPDIR>/build/tmp/work/<machine-name>-poky-linux-gnueabi/linux-yocto/<version>/temp/run.do_compile
In my Yocto system, I have a layer defining a bunch of patches on the linux kernel, as well as a file "defconfig" containing kernel configuration. When I modify this file, changes are reflected in the image I build.
However, a few changes are being overruled and I have a hard time figuring out how or where. I do find a bunch of defconfig files in other layers, but is there any easy way to figure out which ones are applied and in what order?
Thanks
It is not other defconfigs that overrule your configuration (at least not in an even only remotely sane setup), but configuration fragments (creating fragments). You can find out what happens exactly like that:
bitbake -e virtual/kernel | less
(you can of course choose another pager, or redirect to a file for additional processing)
And look for:
KERNEL_FEATURES
--> here you can find a list of kernel configuration fragments in the form of .scc files that are applied to your build
SRC_URI
--> this should mention the path to your defconfig file, and no second one.
Please note that this description only holds entirely true for setups that include a kernel defconfig. If you are working without one, things can be different.
I am currently working on the Linux kernel for an Android phone. My workflow is:
Make changes to kernel code
Build with make bootimage
Flash with fastboot flash boot
This works fine. However building takes unnecessary long because make bootimage first goes through the entire tree and includes all Android.mk files. This takes longer than actually compiling the kernel and creating a boot image. Including these files should not be necessary since there are no changes to them. To decrease turnaround time in my workflow, I would like to speed up the build step.
When building other other projects, there are ways to to not build dependencies and thus skip reading all Android.mk files (for instance mm).
There is a make target bootimage-nodeps which seems to do the right thing: It makes a new boot image without going through all Android.mk files. Unfortunately dependencies also include the kernel itself (which therefore does not get built although there are changes).
My question is: Is there a way to build the kernel and create a boot image withouth having to read all Android.mk files.
In case you 're still looking into it, try using the showcommands goal at make, for example :
make bootimage showcommands
The showcommands goals will show all commands needed to build the kernel and the bootimage. Some of the commands, including the one to create the bootimage have $(hide) in front and are not shown.
Once you know the commands and the arguments, next time you need to make the bootimage you can run the commands manually (without using make bootimage and without including all the makefiles).
I have exactly the same problem and this is the only working solution I've found.
I am not sure if you can save time this way (since this solution needs to zip/unzip multiple times which needs more time then to search for all Android.mks on my machine) but since your question is:
Is there a way to build the kernel and create a boot image withouth
having to read all Android.mk files.
you could give this a try:
Preperations:
call make dist once
unzip the target_files.zip in out/dist/
now create a script that does the following for you:
overwrite the kernel in your unpacked target_files with your newly build kernel
zip your target_files with your new kernel
use the python script img_from_target_files from build/tools/releasetools/ with the extra parameter -z. Example: img_from_target_files -z out/dist/target_files.zip new_imgs.zip
inside the newly created new_imgs.zip you will find your new boot.img with your new kernel
You can try the make SINGLE_SHOTcommand - if you know the path to your Andorid.mk:-
m -j8 ONE_SHOT_MAKEFILE=build/target/board/Android.mk bootimage
This worked for me pretty well in Android L/M/N releases
For a project(Arm i.mx6) I use buildroot for creating my setup.
This works very well.
My problem is that I want to re-use the build to create an installer.
Without using the make clean option.
What I am currently doing:
1]. compile buildroot with file system overlay (A)
2]. Make clean
3]. compile buildroot with file system overlay (B)
This takes a lot of time.
I have tried:
1]. compile buildroot with file system overlay (A)
2]. compile buildroot with file system overlay (B)
But then the files from system overlay (A) are inserted in system overlay (B).
I need A and B because in B I have the installer scripts and the Tar.gz result of A.
What I do not want in B is the scripts of A due to the fact that A has network settings which I do not need in B.
There is at the moment not really a good way to achieve this in buildroot. It is possible to build your toolchain separately and use it for both build configurations. In other words, you would have three configurations:
toolchain_defconfig
overlay_a_defconfig
overlay_b_defconfig
toolchain_defconfig should set BR2_HOST_DIR to point to a permanent location, e.g. /opt/toolchain. The other configs should use a custom external toolchain based at that location.
This option is only possible for the toolchain itself (so compiler and libc). It is not possible to extend the toolchain with additional libraries and use these in the build.
A second possibility is to enable BR2_CCACHE. ccache is able to avoid most of the actual compilation steps. This is particularly helpful for big packages (Qt, Webkit, Node, ...).
Finally, if the only difference between your two configurations is the overlay, you also have the option to build everything except the overlay with buildroot, and write a custom script to combine the tarball generated by buildroot with your overlay and create the final rootfs from that.
As far as I understand you just need two "independent" root file systems. You can create two folders and use them with two different configs:
cd buildroot
mkdir rootfsa
mkdir rootfsb
make O=rootfsa menuconfig
make O=rootfsa
make O=rootfsb menuconfig
make O=rootfsb
Now you have two different rootfs.tar files: one in rootfsa/images and another one in rootfsb/images