How can I rebuild the image after making some modifications to driver source code?
I have tried bitbake -f -c compile and bitbake but I coudn't find the modified settings in the driver. Can someone tell me how can i rebuild the image with the modified code.
I guess that you want to re-generate the whole image, don't you? If so, you can try the following commands to ensure that bitbake won't use the sstate cache:
bitbake image-name -c cleansstate && bitbake image-name
In the case you just want to rebuild the kernel, substitute image-name by virtual/kernel (or the name of whatever recipe you want to rebuild).
Note that the do_cleansstate task is going to remove the recipe ${WORKDIR}!
For further information: https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-tasks-cleansstate
In the case you're doing such modifications directly in the ${WORKDIR}, which you shouldn't unless you're testing, the execution of the following command would be enough:
bitbake virtual/kernel -f -c compile
or
bitbake virtual/kernel -C compile (to invalidate the stamps and force all tasks starting from do_compile)
Since changes in ${WORKDIR} will be rewritten after cleaning, you can put your code to external workspace by command devtool modify <recipe-name>
By default your recipe code will be put into tmp/workspace/source/ directory
Now you can freely modify your code and simply build using bitbake <recipe-name> as usual.
When your modification are OK you can easily save your changes as patches to original recipe code (as far as it is likely open-source and downloaded):
commit your changes in your workspace
in order to automatically create patches and append they to recipe use command devtool recipe-update -a <layer-path> <recipe-name>
If you did your modifications not directly in the ${WORKDIR}, you have to set the SRCREV to your new hash and increase your PR. Then enter the command
bitbake <image-name>
Which compiles the one package again and creates the new image with your changes.
If you did your changes in the ${WORKDIR}, please add, commit and push them to your repository and then follow my steps above. This is the cleanest solution.
The command suggested by other solutions:
bitbake <image-name> -c cleansstate
Will cause all of the packages to rebuild, which can take very long if you don't have an sstate mirror.
Related
I'm trying to change the alsa-utils recipe to add a configure option for the state dir. I need to move it to '/etc'.
I used devtool to modify, edit-recipe, and build without any issues. When I try to update-recipe, I get the following message:
INFO: No patches or local source files needed updating
And it's not creating the .bbappend for my recipe changes. I haven't changed anything in the source directory.
Any ideas of what I'm doing wrong?
update-recipe creates a proper directory tree with .bbappend and .patch files in your layer only if you have commited any changes to the source directory.
If you don't want to create .bbappend manually, commit some changes to the source code you've got via devtool, run update-recipe, remove any reference to the patch file in your newly created recipe.
I made some changes on u-boot source /tmp/work/beaglebone_my-poky-linux-gnueabi/u-boot/1_2018.07-r0/git
When I rebuild with bitbake core-image-minimal. Bitbake is not overwriting images in the path /images/.
Then I used clean, cleansstate, but both of them deleted all my changes in the u-boot/1_2018.07-r0/git directory.
What is the most efficient way to customize the u-boot and kernel?
Thank you.
Changing a recipe's fetched sources directory is not enough to permanently modify source code in Yocto as it is just a temporary working directory that, as you experienced, can be cleaned and all.
Changes to Yocto recipes sources can be made by:
modifying the source code in the working directory
creating a patch for your changes
change/create some recipe to apply your patch
the patch will be applied in build time
This section describes the process of modifying source code and creating a patch:
https://www.yoctoproject.org/docs/1.6.1/kernel-dev/kernel-dev.html#modifying-source-code
This section describes the process of creating an extra layer and a recipe for the patches you created in order to apply them during build time:
https://www.yoctoproject.org/docs/1.6.1/kernel-dev/kernel-dev.html#modifying-source-code
I have a yocto project where I added some recipes and some of the functions in them are crucial when building (the functions consist inly some links creations, some files "equilibristics"). Although when first build all is done and the sstate_cache is saved to shared/sstate_cache so that those recipes are mentioned executed. When I make some changings on building system, also delete some of the built files or the hole build dir and rerun the build, bitbake does not execute the recipes.
The only solution is to:
bitbake -c cleanall <list_of_my_recipes_to_be_rerun>
So I have to explicitly clean the cache to tell bitbake to rerun them.
So my questions are:
Is there some way to explicitly set the recipe to be executed no matter what the shared cache saved on it?
Or maybe save the state locally in the build dir?
Or maybe tell bitbake not to save state for the recipe?
You could set BB_DONT_CACHE = "1" in the recipe, rerun the recipe with the -C option, or make the task checksum depend upon these things which you're changing so it automatically rebuilds when you change them. You could also just clean the recipe and then use the --no-setscene to bitbake.
Easy way:
$ bitbake <recipe> -C unpack
This builds recipe but forces unpack to rerun, which means everything else has to rerun too.
However if the recipe doesn't work with sstate then that is a problem with your recipe.
Is there some way to explicitly set the recipe to be executed no matter what the shared cache saved on it?
To force a recipe to run regardless of what is in the shared-state cache (or anything else),
pass the -f | --force option to the bitbake command, e.g.
bitbake -f [other_options...] recipe_name ...
See the bitbake commmandline options in the manual.
Is it good practice to edit source code in poky/build/tmp/work directory ? because if we accidentally cleansstate ,the changes will be erased.
Alternatively we can edit source code in "files" directory along with recipe file but since mostly code here is in zipped form due to large number of files , so we will need to unzip and zip again just to change one line of code.
So what is best way to edit source code in yocto ?
If your question is about permanent changes, then Dan's answer is the one to follow. I.e. add a <recipe name>.bbappend to the recipe in your own layer, in which you add
SRC_URI += "file://mypatch1.patch \
file://mypatch2.patch \
"
enumerating all the patches you need.
If there's a large number of patches, it might make sense to fork the upstream repository, and maintain your own branch in your fork. In that case, you'll likely want to reference your own repository, instead of either the upstream repository or tarball.
OTOH, if your question was more about work-in-progress; then sure, doing it in oky/build/tmp/workoky/build/tmp/work/xxxx will work. (And quite likely, it's what most people have been doing for a long time).
However, there's a much better way in recent releases (from 1.8, fido). The new tool is called devtool. You can use it as follows:
devtool modify -x <recipe-name> <path-to-unpack-source>
unpacks the source and creates a new bbappend to build from the unpacked source. It also creates a git repo in the source directory.
Now you can modify the source. You can test-build your modified source by running devtool build <recipe-name>. Once you're satisfied, use git add ... and git commit to commit your changes to the local repo. Once you've commited the changes to the local repo, you can run:
devtool update-recipe <recipe-name>
to update the recipe in question. When you're satisfied, you can run devtool reset <recipe-name> to remove the temporary bbappend.
See also: Yocto manual on modifying source code
If you are continuously "patching" a given package manually, I would recommend you to look at implementing a .bbappend file in a separate layer which applies your patch using the do_patch function (http://www.yoctoproject.org/docs/2.0/mega-manual/mega-manual.html#patching-dev-environment).
I am trying to add new c file in place of file that already comes after downloading the package from git.Tried bbappend but the original file is still there.also modified src_uri += file://fileone.c but that is also not overwriting file.
Any suggestions would be of great help
Regards
Mayank
This is where devtool modify can be very helpful if you're using the jethro (2.0) release or later. Assuming you have already sourced the environment setup script:
devtool modify <recipename>
It will tell you where it has extracted the source - cd into that directory.
Make the changes to the file that you want - which could be overwriting it completely.
git commit -a to commit your changes
devtool update-recipe <recipename> -a /path/to/your/custom/layer (assuming you want to create a bbappend in a custom layer, otherwise just omit the -a and path to apply the changes to the original recipe instead).
If you are completely finished, you can devtool reset <recipename> to put everything back to building completely from the metadata.
So the original C file is part of the release tarball (or git, or wherever the release comes from) and you want to replace that file with your own before configure and compile happen?
Replacing the whole file is just a special case of any smaller changes you might want to do the source files, so just do what you would do in those cases: create a patch the replaces the file and add the patch with SRC_URI += file://replace-file-with-my-file.patch.
I use this work flow (in the project source directory, e.g. poky/build/tmp/work/corei7-64-poky-linux/my-project):
# initialize git (only if this is not a git repo already)
git init
git add *
git commit -m "original code"
# <--- here you should replace the file
git commit -a -m "Replace file with a better file"
git format-patch -1
Now you should have a patch file that you can copy into the proper recipe directory.