the Makefile is something like this.
all: host kernel app;
host: host/kconfig;
kernel: kernel/compile kernel/install;
app: app/busybox app/switch app/wifi;
app/busybox: app/busybox/compile app/busybox/install;
app/switch: app/switch/compile app/switch/install;
app/wifi: app/wifi/compile app/wifi/install;
app/busybox/compile:
make -C busybox
the host target build host tools. the kernel target build kernel. the app target build userspace application and kernel modules.
I want to support parallel build. but the parallel strategy and reasons are:
host/kernel/app can't be parallel
build kernel only after host is built, build app only after kernel is built.
but I don't want kernel depends on host, app depends on kernel.
because when I build app solely I don't want the kernel is built.
some app can't be parallel
switch and wifi are kernel modules, so app/switch/compile and app/wifi/compile can't be parallel.
Now I add .NOTPARALLEL to Makefile, so only sub Makefile in rule are parallel, but some targets can actually be parallel, e.g. app/busybox app/boa.
How can I write Makefile to support this flexible parallel build.
Based on your comment what you are really wanting is for the app target to be rebuilt when the kernel target rebuilds, but you don't want to rebuild the kernel target automatically whenever you ask to rebuild the app target.
I'm not sure what this has to do with parallel builds though...??
To do this, just don't have the app target depend on the kernel target at all. If you want to have app rebuild when you do update kernel, then have app depend on some file that gets updated when you rebuild kernel, but don't have a make target describing how to build that file... make will consider it to be like any other source file.
Something like this:
app: .build_target
...build app...
kernel:
....build kernel...
touch .build_target
Or, if the kernel target builds some other file you can have app depend on that and you don't need the touch. Now when you build app it will only get rebuilt if .build_target is newer, but it won't try to build kernel (because make doesn't know how to build .build_target) unless you specifically say make kernel.
ETA
If you want make kernel app to build both, you can do it like this:
app: $(filter kernel,$(MAKECMDGOALS))
This way if kernel appears as a command-line goal then app will depend on it, and if it doesn't it won't.
Related
I've found various kernel configs in kernel/configs/q.
When I alter them, and run mm in kernel/msm-4.14 the kernel is not rebuilt.
Where do I edit the kernel config, such that a kernel rebuild is forced when mm is run?
The kernel is built separately from the Android platform first. Then the Android platform build system is pointed at where the kernel image is located, using the TARGET_PREBUILT_KERNEL environment variable.
Here is an outline of how I usually configure and build. I have done it this way for both Android 9 and 10, for various vendors. The scheme I use is mentioned in the docs here. Non-Google kernels usually don't come with version control (repo), I don't know what you're dealing with so I'll cover both.
Configuring the kernel
For repo-checkout kernels, you do the config in build/build.config. Basically, after defconfig was taken as basis, you use the ${KERNEL_DIR}/scripts/config tool to alter the config. This usually looks as follows:
POST_DEFCONFIG_CMDS="check_defconfig && update_config"
function update_config() {
${KERNEL_DIR}/scripts/config --file ${OUT_DIR}/.config \
-d CONFIG_SOMETHING_I_DISABLE \
-e CONFIG_SOMETHING_I_ENABLE \
--set-val CONFIG_FOO = 123
}
If you don't have a repo-checkout kernel, locations and details may differ but the basic idea is usually the same: Find/Create the script that kicks of the build, and add invocations of the config tool after making defconfig.
Run the config tool by its own to see full options and more info on its usage, but the above is usually all you need. Beware: If you make syntactically-correct invalid changes (e.g. enable symbols of which the dependencies are not met), the build system will NOT complain and ignore these changes silently. If you face this situation, e.g. use menuconfig to find out what's wrong, as it shows dependencies.
Building AOSP / Making boot.img
After you've built your kernel, you will have Image.lz4 in out/.../dist (or Image.gz in out/.../private/msm-google/arch/arm64/boot). You go to your Android source, and in addition to the usual things (source build/envsetup.sh, lunch) you point the build system at the image you built, e.g. export TARGET_PREBUILT_KERNEL=/path/to/Image.lz4. Then just start the build normally, e.g. make bootimage or m droid.
Note that for Android 10 at least in some cases, you'll have to copy over the kernel modules from out/.../dist too, since the new kernel can't load the old ones. With this part, I am having problems myself at the moment. I think they have to be copied to device/VENDOR/DEVICE (e.g. google/coral-kernel), you may also copy your kernel image there btw, since the original prebuilt one also is there by default. The problem is that at least in my case, the new kernel modules were not copied to device after all.
I have a Linux kernel for NXP i.MX6. There are some capture kernel modules in /driver/media/platform/mxc/capture.
One of the files called mxc_v4l2_capture.c. I had to change this file for using it with my own new kernel driver.
I created a repository with my driver and the sources for mxc_v4l2_capture. Then I made a new Yocto recipe in my layer recipies-kernel -> kernel-modules->my-kernel-module.bb
Yocto can build these two kernel modules (my-kernel-module.ko and mxc_v4l2_capture.ko).
Okay, now there is a problem because the kernel recipe already builds the mxc_v4l2_capture module. Therefore I want to manipulate the Makefile for the original kernel modules and exclude the make of mxc_v4l2_capture.
I have created the patch but I don't know how to use the patch with Yocto. Where to place it and how can I call it?
Normally I put a patch into a .bbappend file and finish but I don't know the name of the recipe that build the kernel modules.
It would be great if there is a way without manipulating this Makefile.
Is there a way to solve this with my kernel module recipe?
mxc_v4l2_capture.c is in-tree kernel driver. If you want to change the in-tree driver code and compile, it's highly recommended to patch the kernel and compile the kernel with usual recipe.
Having additional bitbake recipe for the in-tree kernel module is not necessary. To patch the kernel and compile, you can use .bbappend or .bb itself. For example,
if you have recipes-kernel/linux/linux-stable_4.19.75.bb in your Yocto BSP layer, you can add the patch to SRC_URI as below.
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
SRC_URI += "file://mxc_v4l2_capture.patch"
Now, you create recipes-kernel/linux/linux-stable-4.19.75/ and copy the mxc_v4l2_capture.patch file inside.
Or if you don't have permission or not possible to modify the Kernel recipe in BSP layer, you can create .bbappend in your custom layer. For the above example, you can create linux-stable_4.19.75.bbappend (specific version) or linux-stable_%.bbappend (any version). Then place the same content as mentioned above.
Yocto supports various patch formats, refer here for more details.
Look at this answer I wrote some days ago. The steps are basically the same. Using
devtool modify virtual/kernel
will create a working copy in build/workspace where you can do the work you want. Commiting those changes to the local branch and running
devtool finish linux-mainline <path-to-your-layer>
will create a .bbappend file with the patches already created and put to the correct location for you.
If you want to learn how to do it manually follow the advice #Parthiban gave.
How can I ensure that object files compiled for one hardware target will not be used for a different hardware target that needs to be compiled differently?
I am using the GNU ARM Embedded Toolchain while I am learning about embedded development. I already have a couple of development boards (with STM32F0 and STM32F4 processors), and plan to make my own boards in the future. I want to have several iterations of hardware using a common software repository.
Obviously I will have multiple targets in my Makefile, invoking the appropriate defines and compiler flags for each platform, and perhaps a make all to build for all platforms at once. As I understand it, make is an incremental build system that only re-compiles object code (*.o) files if the source file has been changed, it won't recompile if I have use different defines and options, and the wrong object code will be passed to the linker.
It seems that I could diligently make clean when switching between different targets, but that would rely on the human action and could produce bad builds if I forgot, and could not be used for a make all that produces multiple binaries for their respective hardware.
Edit Notes: Per feedback comments, I have shorted and rearranged to make the question more clear and objective. I'm not asking generically how to use Make, but rather how to prevent, say mylib.o being compiled for an STM32F0 and then later being re-used in a build for an STM32F4.
I am curious about alternative tools, and welcome discussion in the comments, but this question is specific to GNU Make.
To avoid the need for a clean build between targets, it is necessary for each target to have separate build directories in order that the target dependencies are independent and specifically generated using the appropriate tool chain and build switches etc.
I need to build mmc_block.ko but with MMC_BLOCK_MINORS=16. I do not wish to build the entire kernel. I am using Ubuntu 15.10. How do I do this?
Dpending on how the Makefile has been written, a module can be compiled out of the kernel tree or in the kernel tree.
Concerning your specific example, I assume the module is the one shipped with the kernel and therefore the Makefile has been written for in-tree compilation. In this case, you can just type make modules to rebuild the module, provided that the kernel has been already compiled (which is a mandatory condition also for out-of-the-tree compilation).
Hey is there anybody who works with SDCC to make projects for 8051 microcontroller series on Macbook. If yes then can you please post the working make file, specially the part which loads the program in the device. I am confused what to write specifically with the program tag in the Makefile.
It is not necessarily the case that a makefile include loading the code to the part, so just any old example will not help. Makefiles are very simple in essence; you have a target, and its dependencies - if the target does not exist, or any dependency is newer than the target, the target is rebuilt by executing the commands.
In your case you need a phony target (one that never exists), that is dependent on the binary image or hex-file (or whatever format you load file is), the the command to execute would be to launch whatever flash-programming or bootloader tool your toolchain uses to load the image:
.PHONY loadimage
loadimage : myprogram.hex
loader.exe myprogram.hex