We want to build a embedded Linux device using Yocto which is SELinux Enabled.
I was looking at meta-selinux layer Dependencies.
Dependencies
This layer depends on the openembedded-core metadata and the
meta-python and meta-oe layers from the meta-openembedded repository.
When it is referring to 'openembedded-core' does it mean poky
git://git.yoctoproject.org/poky
or
https://github.com/openembedded/openembedded-core
What are the differences between poky and openembedded-core, i don't see bitbake in openembedded-core
OpenEmbedded/Yocto Project is a superset project, from this superset, a subset (poky) is created so people can get a taste of OE.
Poky distribution is made using components from OE, demo BSPs, helper scripts to easily setup build environment, QEMU emulator to test the image, and the bitbake task scheduler. This make poky a ready-to-cook subset of OpenEmbedded (OE) that helps users to understand the build system and to create their own Linux distribution possibly based on Poky distro.
Poky is a reference distribution of the Yocto Project. It contains the OpenEmbedded Build System (BitBake and OpenEmbedded Core) as well as a set of metadata to get you started building your own distro. See https://www.yoctoproject.org/software-item/poky/
Related
We are planning to release our Embedded Linux product using Yocto.
Currently, I see 'Warrior' is the stable release version.
https://wiki.yoctoproject.org/wiki/Releases
Looking at the poky source code, I find lot of tags.
https://git.yoctoproject.org/cgit/cgit.cgi/poky/refs/tags
How to decide on choosing the tag. I see poky-yocto tag, poky-warrior tag
Unless your hardware supplier provides you with a customized Yocto version (usually a Linux kernel, related patches and some recipes to setup specific hardware), you should always start with the latest stable version available at the moment, because it will contain the latest fixes from the community, and probably you are interested on them.
I need realtek-8192cu driver in my linux version.
The default driver shipped with kernel is not suitable for me.
I want to use a custom version of driver like https://github.com/desflynn/realtek-8192cu-concurrent-softAP.
How to create a recipe for that job.
Thanks,
one possibility is to use the bitbake recipe hello-mod_0.1.bb as starting point to build a recipe for external kernel modules. It can be found at openembedded-core/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
The Reference to Incorporating Out-of-Tree Modules: https://www.yoctoproject.org/docs/2.3.2/mega-manual/mega-manual.html#incorporating-out-of-tree-modules
I am currently working with creating an alternative BSP using Yocto to replace the existing BSP. I am new to Yocto and I need to know how I can add libusb support to Yocto to detect the bluetooth dongle when attached.
Regards,
Pavan
You could use OpenEmbedded Layer Index to search for recipes available in Yocto. libusb1 recipe is here.
Then, to add that recipe to your Image, in /build/conf/local.conf, add IMAGE_INSTALL_append = " libusb1 "
Another option is to create core-image-full-cmdline for a console-only image with more full-featured Linux system
functionality installed.
Where can I get compiled libraries specific architectures? My company hired some contractors to port some code to our powerpc platform. I am trying to move this to an arm platform(omap3).
They created a cross compiling environment(in Windows). All of the libraries that are linked at still compiled for PowerPC. For each lib there are 3 files: .so, .so.X and .so.X.Y.Z I can get the second 2 from the deb packages and I found the .so in developer deb package but it is 0 bytes.
Any help would be great.
Maybe in Angstrom?
Theres no way (that I know of) to convert a binary from machine A(power pc) into binaries for machine B(arm). If you have the source, or a way of acquiring the source, you can rebuild them for your arm target. You can accomplish this by either using a local compiler on a arm machine, or cross compile using a cross compiling tool chain (eg code sorcery lite (http://www.codesourcery.com/sgpp/lite/arm) to build libraries from your build machine onto your arm target. Most libraries are not obtainable on arm in a pre-compiled form.
Depending on what OS you're using on your arm target, eg debian or redhat. There may be a package manager available to do this for you.
I'd like to set up a cross-compilation environment on a Ubuntu 9.10 box. From the documents I've read so far (these ones, for example) this involves compiling the toolchain of the target platforms.
My question is: how do you determine the required version of each of the packages in the toolchain for a specific target platform? Is there any rule of thumb I can follow?
This is a list found in one of the websites linked above:
binutils-2.16.1.tar.bz2
linux-2.6.20.1.tar.bz2
glibc-2.5.tar.bz2
glibc-linuxthreads-2.5.tar.bz2
gcc-core-4.2.0.tar.bz2
gcc-g++-4.2.0.tar.bz2
But suppose I want to generate executables for standard Ubuntu 8.04 and CentOS 5.3 boxes. What are the necessary packages?
My primary need is to avoid errors like "/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found" in the customers' machines but in the future I want to deal with different architectures as well.
It is generally a good idea to build a cross-toolchain that uses the same version of libc (and other libraries) found on the target system. This is especially important in the case of libraries that use versioned symbols or you could wind up with errors like "/usr/lib/libstdc++.so.6: version 'GLIBCXX_3.4.11' not found".
Same Architecture
For generating executables for standard Ubuntu 8.04 and CentOS 5.3 systems, you could install the distributions in virtual machines and do the necessary compilation from within the virtual machine to guarantee the resulting binaries are compatible with the library versions from each distribution.
Another option would be to setup chroot build environments instead of virtual machines for the target distributions.
You could also build toolchains targeted at different environments (different library versions) and build under your Ubuntu 9.10 environment without using virtual machines or chroot environments. I have used Dan Kegel's crosstool for creating such cross-toolchains.
Different Architecture
As I noted in my answer to a another cross-compiler question, I used Dan Kegel's crosstool for creating my arm cross-toolchain.
It appears it may be slightly out of date, but there is a matrix of build results for various architectures to help determine a suitable combination of gcc, glibc, binutils, and linux kernel headers.
Required Package Versions
In my experience, there really isn't a rule of thumb. Not all combinations of gcc, binutils, glibc, and linux headers will build successfully. Even if the build completes, some level of testing is necessary to validate the build's success. This is sometimes done by compiling the Linux kernel with your new cross-toolchain. Depending on the target system and architecture, some patching of the source may be necessary to produce a successful build.
Since you are setting up this cross-compilation environment on Ubuntu 9.10, you might want to look into the dpkg-cross package.
Compiling for other Linux distributions is easiest by installing them in virtual machines (apt-get install kvm) and then doing the compilation from within. You can also script them to do it automatically. Building a cross-compiler and providing the exact same versions of all libraries and such, as the other Linux distro does, is nearly impossible.
My question is: how do you determine
the required version of each of the
packages in the toolchain for a
specific target platform?
...
binutils-2.16.1.tar.bz2
gcc-core-4.2.0.tar.bz2
gcc-g++-4.2.0.tar.bz2
Generally pick the latest stable: these only affect your local toolchain, not runtime.
linux-2.6.20.1.tar.bz2
You don't need this. (For targeting embedded platforms you might use it.)
glibc-2.5.tar.bz2
glibc-linuxthreads-2.5.tar.bz2
You don't need these. I.e. you should not download them or build them; you should link against the versions from the oldest distro you want to support.
Is there any
rule of thumb I can follow?
But suppose I want to generate
executables for standard Ubuntu 8.04
and CentOS 5.3 boxes. What are the
necessary packages?
You survey the distros you want to target, find the lowest common denominator versions of
of libc, libstdc++, pthreads, and any other shared library you will link with, then copy these libs and corresponding headers from the box that has these LCD versions to your toolchain.
[edit] I should clarify, you really want to get all the dependent libs from a single system. Picking and choosing the LCD of each file version from different distributions is a recipe for a quick trip to dependency hell.
Depending on your target platforms, have you considered using Optware?
I'm currently working on getting Mono and Moonlight built for my Palm Pre using the cross-compilation toolchain (and the Optware makefiles handle the majority of dependencies already).