I’m trying to modify the u-boot-mdm recipe using devtool modify u-boot-edm. It doesn’t appear to matter where I put the unpacked files (my own directory or one in the ‘workspace’ layer), there are immediate problems: I either get messages like ‘error BLAH is required for Mender to work’, or problems with ‘do_mender_tar_src’.
Since Mender seems to be a common factor, I am wondering if meta-mender is not suited to use with devtool
I personally do not use devtool and we do not have any tests to ensure it works either, meaning that their could be issues with it in combination with meta-mender.
But I would expect the problems to be isolated to the “u-boot” recipes, as this is where we have a lot of specialized logic and this is also where the do_mender_tar_src task is defined which you see in your error logs.
If you are able to find out what is causing the problems, please feel free to submit a PR.
03-r0/temp/log.do_mender_tar_src.22367
DEBUG: Executing shell function do_mender_tar_src
tar: git: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
WARNING: exit code 2 from a shell command.
ERROR: Function failed: do_mender_tar_src (log file is located at /home/brian/imx-yocto-bsp/build_evk/tmp/work/imx6ull_theopolis-poky-linux-gnueabi/u-boot-imx/2017.03-r0/temp/log.do_mender_tar_src.22367)
Is there a recommended way of building u-boot after mender integration? If I try to extract the source and build I get the following errors:
make
scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/config.h
CFG u-boot.cfg
In file included from include/config.h:10:0,
from ./include/common.h:21:
include/config_mender.h:32:3: error: #error CONFIG_BOOTCOUNT_LIMIT is required for Mender to work
# error CONFIG_BOOTCOUNT_LIMIT is required for Mender to work
^~~~~
include/config_mender.h:37:3: error: #error CONFIG_BOOTCOUNT_ENV is required for Mender to work
# error CONFIG_BOOTCOUNT_ENV is required for Mender to work
^~~~~
include/config_mender.h:41:3: error: #error CONFIG_SYS_MMC_ENV_DEV should not be defined explicitly (will be auto-configured).
# error CONFIG_SYS_MMC_ENV_DEV should not be defined explicitly (will be auto-configured).
^~~~~
include/config_mender.h:44:3: error: #error CONFIG_SYS_MMC_ENV_PART should not be defined explicitly (will be auto-configured).
# error CONFIG_SYS_MMC_ENV_PART should not be defined explicitly (will be auto-configured).
^~~~~
include/config_mender.h:47:3: error: #error CONFIG_ENV_OFFSET should not be defined explicitly (will be auto-configured).
# error CONFIG_ENV_OFFSET should not be defined explicitly (will be auto-configured).
^~~~~
include/config_mender.h:54:3: error: #error 'CONFIG_ENV_SIZE' define must be equal to bitbake variable 'BOOTENV_SIZE' set in U-Boot build recipe.
# error 'CONFIG_ENV_SIZE' define must be equal to bitbake variable 'BOOTENV_SIZE' set in U-Boot build recipe.
^~~~~
scripts/Makefile.autoconf:79: recipe for target 'u-boot.cfg' failed
make[1]: *** [u-boot.cfg] Error 1
make: *** No rule to make target 'include/config/auto.conf', needed by 'include/config/uboot.release'. Stop.
I have a build server for doing our yocto builds (24 cores, 48Gb RAM etc), but if I am working on the kernel or u-boot I tend to get the source and build locally on my laptop.
One way to do this is to use devtool modify then either use devtool build to build in place on the server, or copy the source to my laptop and source the sdk and build there instead.
Another way is to get the source is to use the devshell and copy the source from there.
So if you want to e.g. add some new code to u-boot then is your process:
Open the devshell: bitbake u-boot -c devshell
Edit your files
Close the devshell
Compile using bitbake u-boot -c compile
Return to 1. if there is more to do
Once you are happy, create patches from the devshell source area.
Exactly, but keep in mind that I tend to do very small change sets nowadays and this is typically a process I use to create Mender integration patches.
If I was to do bigger changes on u-boot or Linux kernel sources I would also prefer to have a working tree locally. The few times I have needed this I have done it manually:
copy source (git clone of SRC_URI and SRC_REV)
copy and apply patches from Yocto layers
make changes
The devtool modify and devtool build process sounds neet but have not yet have the need to learn it .
But in the end it would be nice to fix meta-mender not to break the devtool workflow, and I do not believe that we have intentionally broken this. It might be possible that the problem is in devtool and meta-mender only triggers it. But someone needs to do some digging.
Yes, the devtool is a nice tool. It keeps a git repo of the changes you make.
You commit as you go along. You can then issue devtool finish on your recipe and specify a target layer. It will then create the bbappends and patches in that layer - one patch per commit.
I am not good enough with Yocto to even know where to start debugging this to be honest, and I have to deal with it seldomly so I don’t really build the skills up enough.