I was using buildroot previously and now I am switching to Yocto. There is .config file generated by buildroot which contains all the packages that are going to be present in the file system, the compiler used, kernel version and bootloader etc.
Do we have something similar to this in Yocto. Or is there any bitbake command like make menuconfig.
I have seen some lines in recipes like the below:
if 'CONFIG_UBOOT=y\n' in features:
What is features here means
Thanks for your time
There is no .config in yocto, But yocto maintains a list of packages that are installed in the rootfs image in a .manifest files located at
Manifest Path: build/tmp/deploy/images/<machine>/<rootfs_image_name>.manifest.
Related
I am using Buildroot to produce root filesystem and kernel for my BeagleBone Black. Currently I provide my custom kernel to buildroot. But I noticed there is several ready-made kernels for BeagleBone Black on GitHub.
Since Buildroot allows to download kernel source directly from a git repository, I should be able just to point Buildroot to the BeagleBone's kernel repository on GitHub and Buildroot should download and compile the kernel for me.
Unfortunately the things are not so easy. When I specify BeagleBone's kernel repository in Buildroot, the kernel source is successfully cloned, but there is no default configuration and maybe some patch work is also necessary.
Did anybody try to integrate Buildroot with BeagleBone's GitHub's kernel sources?
Why don't you use the beaglebone_defconfig configuration provided by Buildroot. It uses a 4.4 kernel for the BeagleBone, fetched from git://git.ti.com/processor-sdk/processor-sdk-linux.git.
I'm trying to apply a patch to my kernel source with limited success. The target machine is really some ARM device, but I haven't compiled a kernel before so I thought I'd start with an x86_64 kernel. This has been only marginally easier :)
Now, according to some tutorials, it seemed like we should use the source in /usr/src/linux-something. But when I tried to patch there I got
File Documentation/sysrq.txt is read-only; trying to patch anyway
patch: **** Can't create temporary file Documentation/sysrq.txt.oG1oiZW : Permission denied
even under sudo. So I tried just copying the patch and the linux source folder to my home directory and patched it from there. This worked. Why is this and will this have any weird side effects when compiling?
It seems you have no permission to /usr/src/linux-something. Download kernel source, put it anywere you could, then patch & compile it.
Build a x86_64 arch kernel from source which downloaded from kernel.org is well, if you wanna build an arm arch kernel for a special board, use buildroot or openwrt is better.
The package manager for some distributions installs the kernel source in /usr/src and distribution-specific build scripts may assume that the source is in that directory.
However, if you download vanilla kernel source from kernel.org, you should be able to build it anywhere.
I am using Yocto(poky) freescale linux for creating new software. I have compiled my binaries for this system. But to build rpm package on this system I can not find rpmbuild command.
Do I need to use rpmbuild or opkg or anything else to create package on Yocto?
Thanks in advance.
You will need to create a bitbake recipe for your software. This recipe describes how that software is configured, built and packaged. If your target image is configured with rpm as a package manager, the result of executing that recipe will be an RPM file containing your software. See here: https://www.yoctoproject.org/docs/2.0/dev-manual/dev-manual.html
To add additional binaries or libraries for your project in Yocto,
you can add them in the recipes-extended/merger-files/merge directory.
Any files and directories copied to the "merge" directory will be copied
to the root filesystem created by Yocto.
I want to use Yocto to build a linux dist from my own sources (not Arago sources).
I have installed Yocto eclipse plugin, but I can't configure the compiler toolchain.
I have the ti-sdk-am335x-evm-07.00.00.00 SDK installed, and would like to use it
to compile my own dist.
In the Yocto Project ADT preferences in eclipse, what do I specify for:
Toolchain Root Location
And
Sysroot Location?
It won't show up a target architecture, when I try to configure it. What folders should I set?
First, make sure that you built the toolchain, or otherwise made it available. Try this:
bitbake meta-ide-support
That will build a script that you can source in another directory to have access to the toolchain.
Did you check out the Yocto Manual? Specifically, look at section:
4.2.2.1.4.1. Configuring the Cross-Compiler Options
What I've gotten to work is this:
Toolchain Root Location: the manual says the top of the build directory, but for me it won't work unless I have it at build/tmp. In other words, the Toolchain Root Directory is the directory right above where the environment setup script got built.
Sysroot Directory: build/tmp/sysroots/
Also, try with "Standalone pre-built toolchain" selected instead of "Build system derived toolchain," as discussed here.
I've got a Raspberry PI with Emdebian installed on it, and want to cross-compile projects.
There is plenty of documentation on how to obtain a toolchain and build a simple project with it. I myself managed to build a toolchain with crosstool-ng and wrote a hello world program which works fine.
What I don't get is how to handle cross-compiling more complex projects like Qt, which have dependencies on other libraries. Let's use libdbus as an example, as that is one of Qt's dependencies.
The installed Emdebian already contains libdbus.so, so naturally I'd prefer to use that, instead of cross-compiling my own libdbus.so, as compiling all of Qt's dependencies would take a lot of time.
For cross-compiling, there are two important directories, as far as I understand:
The "staging" directory, where all the installed libraries and applications live. This initially is a copy of the toolchain's sysroot directory, and gets populated with more libraries as they are cross-compiled.
The "rootfs" directory, which is equivalent to what is on the device - essentially a copy of the staging directory without unneeded stuff like documentation and header files. As far as I understand it, the best approach is to copy required files from the staging directory into the rootfs.
Getting the rootfs directory is easy, as that can be a NFS mount from the device. But how do I get a staging directory for the existing Emdebian installation on the PI? The staging directory needs to include things like dbus headers, which are not installed on the rootfs.
Some people simply install the dbus headers on the device, with apt-get install libdbus-dev, and then use the rootfs as the staging directory. With this setup, there is no distinction between rootfs and staging anymore, with the disadvantage that the rootfs is polluted with headers, documentation and so on. The advantage of course is that it is easy.
What is the best way to get the dbus headers into my staging directory on my host machine? What is the usual approach people use in this situation?
As a side question, why does the approach of obtaining a toolchain, compiling a program and then copying that on a target work at all? The toolchain ships its own versions of libc, libstdc++ etc, are they not incompatible with the versions that are installed on the target? Especially when creating using a custom toolchain compiled with crosstool-ng?
(Note that I am not asking how to compile Qt, I can figure that out myself. My question is more general, about the approach to take when combining a custom toolchain with an existing installation/rootfs)
In my experience, you don't need to compile your dbus. You can do it as
Create Debian cross rootfs by debootstrap by https://wiki.debian.org/EmDebian/CrossDebootstrap
Create your cros-compile toolchain by crosstool-ng, and make sure the kernel version and eglibc version are the same as rootfs created by 1st step
Build QT by
CPPFLAGS=-I<rootfs>/usr/include \
LDFLAGS=-L<rootfs>/lib -L<rootfs>/usr/lib -Wl,-rpath-link,<rootfs>/lib,<rootfs>/usr/lib \
./configure <your options>
make
Install QT into the stage directory by
make install DESTDIR=<stage directory>
Copy QT dependent libraries from rootfs the your stage directory
So you can see that, the stage directory is kept minimum without pollution.