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...
Related
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.
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 am trying to add my own device driver to Linux kernel with Yocto Project.
I added my configuration like CONFIG_MY_DRIVER=y into the defconfig file in the BSP layer folder, meta-bsp/recipes-kernel/linux/linux-my/ and modified the bb file by adding SRC_URI += "file://defconfig".
After BitBake, I found that the .config file in the build directory didn't have CONFIG_MY_DRIVER=y, but the .config.old file did. It seems that the .config file has been overwritten by some background task. I am not familiar with it, can anyone help me to figure out it?
At the same you have to copy the CONFIG_MY_DRIVER=y into receipe-kernel/linux/linux-my/defconfig ,defconfig should reflected after adding the option into the yocto layer, Then fetch into kernel .bblayer
SRC_URI = "git address file://defconfig"
then start the bitbake server.
I like to disable and enable some pins in my RPi project.
These are GPIO 6, GPIO 5 and GPIO 26. I like to use these PINs in my own kernel driver.
For this project I connect a simple electric board via the GPIOs. The minimal system is build via yocto. I like to change the device tree file to disable/enable GPIOs.
I need to change or make my own dts file. For that I think I will need to:
find the original RPi dts
patch it or create my own dts
add it to the layer.conf
add file to the kernel recipe via append
How can I do this? or where can I find the sources?
Actually I am struggling to find the dts files for the RPi2 I am using. I was checking the "raspberrypi2-poky-linux-gnueabi" recipe results(and do not find any files).
I do not find any tutorial how to setup yocto + meta-raspberrypi + own dts. it would be great if we can figure out the necessary steps.
I'm not convinced this question has been well answered, so let me take a few minutes and document what I've done to add device tree overlays to my yocto builds.
This is a multi-problem process.
I'm going to make a few assumptions:
* You source your oe-init-build-env in a shell, and do your bitbake builds manually in a terminal (or you know how to do it with equivalent tooling)
* You know (or are already learning) the basics of device trees...
Start with your own meta layer. Mine is out on github.
You'll need to create an *-overlay.dts source file. You can start with a simple place holder, and stuff it (quite literally) anywhere on your system. We'll import it to your meta layer in the next step using bitbake to do some of the staging and what-not for us.
recipetool appendsrcfile -wm rpi /path/to/your-layer-meta virtual/kernel /path/to/your-overlay.dts 'arch/${ARCH}/boot/dts/overlays/your-overlay.dts
At this point, you should end up with a recipes-kernel/linux directory with an appropriate bbappend targeting the $MACHINE type of -wm (rpi, as above), ready to copy the device tree source file into the proper spot for bitbake to find it when it building the kernel. But it still won't be included in your kernel build.
We need to add the overlay reference to the KERNEL_DEVICETREE variable, in places that will cover the scopes of: linux, bootfiles, and the sdcard_image-rpi.bbclass from meta-raspberrypi.
In the linux bbappend created in step 3, add KERNEL_DEVICETREE += "overlays/your-overlay.dtbo" to make the linux kernel build include your dts as something to compile into a dtbo.
To make the sdcard_image-rpi.bbclass copy the file, you'll need to add KERNEL_DEVICETREE =+ "overlays/your-overlay.dtbo" to your image recipe.
To make the overlay active, you'll need to create a recipes-bsp/bootfiles/rpi-config_git.bbappend whereyou can append a do_deploy step to add the dtoverlay=your line to config.txt.
I use my layer for more than one project, so I felt OK with having the dts compile with every kernel but only copy it to images where my image recipe added it to the KERNEL_DEVICETREE. For further insurance that I don't get these things interferring in images I don't want them in, my rpi-config append has a test to see if I should add the dtoverlay line to the config.txt
Of course, this was all assuming you were going to use your own home-grown DTS without starting from a kernel-sourced one. The process would be largely the same, but you'd be able to patch the existing, or copy it, or whatever you want to do in your linux recipe.
I hope this helps! I know it's an old question.
First you need to find the kernel used on your yocto project, the recipe is linux-raspberry.bb or something like linux-*.bb. The preferred kernel is probably set in your local.conf or machine.conf: PREFERRED_PROVIDER_virtual/kernel ?= "linux-raspberry"
This is indirectly set via "meta-raspberrypi/conf/machine/include/rpi-default-providers.inc" which is included via "rpi-base.inc"
Once found, take a look at the recipe, clone the git repository of the kernel, on the right branch, and reset at the right SRCREV.
Once downloaded, the dts files are in /path/of/my/kernel/linux-raspberry/arch/arm/boot/dts/. You can find the name of the devicetree file used in the kernel recipe, local.conf or machine.conf, with the variable KERNEL_DEVICETREE = "..."
For the meta-raspberry and rpi2 selected, the dts files can be found in <path to build dir>/linux-raspberrypi2-standard-build/source/arch/arm/boot/dts/. The source dir is a linked dir to the git sources.
You can add a new dtb by creating dtsi/dts files (don't forget to add it in the Makefile).
Create a patch, add it to the kernel recipe:
SRC_URI += "file://0001-mypatch.patch"
and put the patch file like this in your meta
├── files
│ └── 0001-mypatch.patch
└── linux-raspberry.bb
Modify the KERNEL_DEVICETREE variable to add your new dtb.
Now you can bitbake your kernel/image, your new dtb will be created.
I'm trying to figure out how to convince Yocto to build gcc using my local GIT source rather than standard location it uses.
By default the recipe to build GCC located in meta/recipes-devtools/gcc/gcc_5.2.bb. It includes gcc-5.2.inc, which points to
BASEURI = "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2"
as the location of the code.
Based on BitBake's documentation, I've created my own layer and gcc_5.2.bbappend append file. bitbake-layers show-appends shows that the system properly recognized the append file.
However, what this gcc_5.2.bbappend append file need to do to replace the source path? I've tried changing SRC_URI directly, prepending it with my own path. But it always stays the same and attempts to access the specified above path.
My original assumption that the /gcc/gcc_5.2.bb have to appended was incorrect. I've corrupted the specified above BASEURI to consistently cause an error. Running bitbake with -D option showed that there is a different recipe called gcc-source_5.2.bb that actually controls the source file acquisition and it had to be appended.