I'm trying to find the correct value for the KMACHINE setting, defined as "The machine as known by the kernel."
When I manually configure the kernel (outside of Yocto) I do not enter a machine type. I do set ARCH=arm, choose a "system type" config option like CONFIG_ARCH_LPC32XX=y, or load a defconfig like lpc32xx_defconfig but I don't know if any of those is what KMACHINE is supposed to be.
As an example, the Yocto documentation gives intel-core2-32 which does not appear anywhere the Linux 5.15 sources.
KMACHINE is used to select Yocto-specific metadata for building the kernel, and is not passed to the kernel build system. By default, it is set to ${MACHINE} in kernel-yocto.bbclass, and can be overridden if a machine does not need its own metadata selection, and can instead use an existing metadata.
There's a better description under LINUX_KERNEL_TYPE in the manual (paraphrased):
The KMACHINE and LINUX_KERNEL_TYPE variables define the search arguments used by Yocto's kernel tools to find the appropriate description within Yocto's kernel metadata with which to build out the kernel sources and configuration.
This kernel metadata is maintained by the Yocto Project, in the yocto-kernel-cache repository. It is optional, and is only used if the selected kernel recipe is a "linux-yocto" style recipe (i.e. it inherits linux-yocto.inc).
If you're using an out-of-kernel-tree defconfig to configure your kernel, it's unlikely you'll need Yocto's kernel metadata, and therefore don't need to override KMACHINE.
Related
Is it possible to have a host package in external tree of buildroot (the tree that is specified by BR2_EXTERNAL variable)? I know that I can implement such package and if there exists any package that depends on it, it will be built. But what if no board package depends on it? That could be the case for example when we need to build a simulator for the supported board. In other words, I need something like Config.in.host in the external directory.
The BR2_EXTERNAL directory needs to contain a top-level Config.in. From there, you can source a host package's Config.in.host just like you do for a target package.
There is no separate Config.in.host for the external, though, so it will never appear in the Host utilities menu, but always in the External options menu.
I have customized buildroot with the new board ( derived from raspberry pi zero ). So my changes are (in-tree):
.config
board/passkeeper/genimage-passkeeper.cfg
board/passkeeper/post-build.sh
board/passkeeper/post-image.sh
board/passkeeper/rootfs_overlay/etc/init.d/S41passkeeper
board/passkeeper/rootfs_overlay/etc/mdev.conf
board/passkeeper/rootfs_overlay/etc/udhcpd.conf
configs/passkeeper_defconfig
output/build/linux-custom/.config
Now, reading the documentation - I am a bit confused on how to put all these things into the separate folder via BR2_EXTERNAL. Also I'm not sure how do I move the linux configuration from output/build/linux-custom/.config
make linux-update-defconfig BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE=/tmp/passkeeper/linux/linux-config
results in
Unable to perform linux-update-defconfig when using a defconfig rule
Can somebody please provide step-by-step guide on that?
[You are asking two questions. I will answer only the question about saving the linux .config file; the other question is too generic.]
You need to set the appropriate options in menuconfig, not just override on the command line, otherwise they are inconsistent.
The process complete for creating a linux defconfig based on a pre-existing in-tree defconfig is the following. You have already done steps 1, 2 and 3.
In the Buildroot configuration, select BR2_LINUX_KERNEL_USE_DEFCONFIG or BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG.
Run make linux-menuconfig and adapt the linux configuration to your needs.
Build and test, iterate over 2 until you have the configuration you want.
In the Buildroot configuration, switch to BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG and set BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE to the place where you want to save it (typically board/passkeeper/linux.config or $(BR2_EXTERNAL_PASSKEEPER)/board/passkeeper/linux.config if you are using an external).
Run make linux-update-defconfig. It is essential you do this before doing anything else, otherwise Buildroot will complain that the file doesn't exist.
I am new in Buildroot. I have linux kernel sources for P2041RDB NXP board, so where I should to place it and how to set this location in configuration?
There is currently no way to set the path to the kernel source from the Buildroot configuration.
You have two options to do it.
Create a file local.mk in the directory that contains .config (i.e. the Buildroot source directory if you don't use the O= option, or the output directory if you do use O=). In local.mk, add a line with LINUX_OVERRIDE_SRCDIR= and fill in the path to the kernel source (either an absolute path, or a path relative to the Buildroot source directory).
Create a tarball of the kernel source. In the Buildroot configuration menu, under "Kernel", set "Kernel version" to "Custom tarball". Then set "URL of custom kernel tarball" to the file-URL, so file:///path/to/the/tarball.tar.gz.
Obviously, in either case, you need to enable the kernel build ("Linux kernel" option in the Kernel menu) and also set the other kernel options (kernel config, device tree, etc.).
using local.mk works, BUT you need to also include
LINUX_HEADERS_OVERRIDE_SRCDIR = in the local.mk file if you're building the cross compiler as well...
For an application I am running, there is a run time error as it cannot find libwayland-client.so.0 shared object. How do I know which package provides it and where do I add it. I tried as shown below but it gave me a Nothing PROVIDES error.
CORE_IMAGE_EXTRA_INSTALL += "libwayland-client"
You don't typically work with single files when building Yocto images
In reverse order
You install packages to the image
You build packages by using a recipe
You find (or as a last resort write) recipes as part of layers.
Generally when something is missing you take the following steps:
Check the layerindex https://layers.openembedded.org/layerindex/branch/master/recipes/?q=wayland It tells you that there is a recipe called wayland in layer openembedded-core
Add the layer in question. openembedded-core is already contained in Yocto's poky (directly under the name meta, just to confuse the newcomer...), so nothing to add in this example
Create the environment listing of the recipe in question, bitbake -e wayland >wayland.env
Check what packages the recipe in question creates grep ^PACKAGES= wayland.env. In this case it is easy because there is really only one package wayland (-debug, -dev etc. are special purpose that would not contain the library)
Add a package to the image by its package name. How to do that exactly depends on the image type you create. The variable name given in the question works for some images, but not all. Search for IMAGE_INSTALL in the manual https://www.yoctoproject.org/docs/2.6.1/mega-manual/mega-manual.html for other options.
Once you have built the recipe in question you can also check what files are contained in a package (In this case recipe name and package name are identical, but that is not always the case. Some recipes build more than one package suitable for installation, so obviously they need to use different names)
$ oe-pkgdata-util list-pkg-files wayland
wayland:
/usr/lib/libwayland-client.so.0
/usr/lib/libwayland-client.so.0.3.0
/usr/lib/libwayland-cursor.so.0
/usr/lib/libwayland-cursor.so.0.0.0
/usr/lib/libwayland-server.so.0
/usr/lib/libwayland-server.so.0.1.0
As far as we can see, to use a library in Matlab it is necessary to add its path to the global Matlab application path e.g. to use the xunit unit testing library, its path must be added to the global path through the user interface. The problems with this are:
Each developer must set the dependency paths correctly on their machine, test machines and build machines etc. to be able to run the code correctly
We cannot set the paths for each developer centrally so when dependencies change, we must issue instructions for individuals to manually change their configuration
If different projects use incompatible dependencies then the path must be reconfigured between changing projects
For C++\C#\Java etc. projects, it is possible to refer to libraries with relative paths from within the project and not require changes to global environment variables.
How can we achieve this with Matlab?
You can use the addpath and rmpath commands to manually edit MATLAB's Path. Paths added via these two commands can be relative paths.