https://wiki.yoctoproject.org/wiki/api.php?action=feedcontributions&user=Dennis+Meier&feedformat=atomYocto Project - User contributions [en]2024-03-19T04:57:30ZUser contributionsMediaWiki 1.39.5https://wiki.yoctoproject.org/wiki/index.php?title=FAQ&diff=11793FAQ2013-12-18T12:14:54Z<p>Dennis Meier: /* Technical */</p>
<hr />
<div>=== Yocto Project Public Messages and FAQ ===<br />
<br />
Last edited: 28 Sept, 2012<br />
<br />
Note: technical FAQs are being added to the end of this document<br />
<br />
<br />
==== What is the Yocto Project? ====<br />
<br />
The Yocto Project provides open source, high-quality infrastructure and tools to help developers create their own custom Linux distributions for any hardware architecture and across multiple market segments. The Yocto Project is intended to provide a helpful starting point for developers. The Yocto Project hosts other projects as well, including the Poky build system, Autobuilder automated build and test system, and the Embedded GLIBC (EGLIBC)C library. The Linux Foundation welcomes the participation of embedded vendors, developers, and other open source projects.<br />
<br />
<br />
<br />
==== What does the Linux Foundation hope to achieve with the Yocto Project? ====<br />
<br />
This year’s annual survey of embedded developers conducted by Embedded Market Forecasters reported that the two primary factors contributing to embedded developers’ choice of Operating Systems (OS) in their designs are cost (44.6%) and the availability of source code (33.1%). These factors have contributed to the explosion of demand for Linux in embedded devices. Until now, embedded vendors and their partners relied on deep customization, requiring developers to wrestle with rapidly changing software and difficult build and maintenance cycles. The Linux Foundation recognized that an opportunity existed for a collaboratively developed, open source project that would build high-quality tools for the embedded Linux ecosystem. <br />
<br />
<br />
<br />
==== How does the Yocto Project help Linux reach a wider embedded audience? ====<br />
<br />
This set of collaboratively developed, open source development tools focused on the embedded segment speeds embedded vendors’ time to market by establishing a shared build infrastructure. This enables Linux across the widest possible spectrum of devices, projects, and platforms. The Yocto Project has a great start on the code required to solve these problems.<br />
<br />
<br />
<br />
==== Isn’t the Yocto Project just yet another Linux distribution? ====<br />
<br />
No. The Yocto Project is a set of tools and components, including a highly configurable build system, that enables developers to construct their own custom distributions, targeted for specific embedded devices. It is not, itself, a Linux distribution. Rather, it is capable of producing an image for a particular embedded device without dictating the composition of the Linux distribution actually built or the hardware architecture used.<br />
<br />
<br />
<br />
==== What benefits does the Yocto Project provide embedded developers and how is the Yocto Project superior to existing, similar tools? ====<br />
<br />
Unlike build systems based on shell scripts or makefiles, the Yocto Project automates how source is fetched from a variety of upstream sources or from local project repositories. Updating to a new version of a package is often as easy as renaming a recipe file. It has a powerful customization architecture that allows the choice of a wide variety of footprint sizes as well as control over the choice or absence of components such as graphics subsystems, visualization middleware, and services.<br />
<br />
<br />
A complete set of Linux package versions is specified in the metadata for the project; these versions are known to work correctly together. A robust effort within the project is dedicated to keeping this selection of packages fresh and up-to-date. Unlike other systems, however, only a single version of each package is typically provided with the project at any given time. This ensures that the packages are known to work well together, while providing the freedom to replace them at any time as the needs of a given embedded project mature.<br />
<br />
<br />
The Yocto Project is package-format agnostic - supporting both major Linux packaging systems (.rpm and .deb), as well as the embedded-friendly ipk format. The Yocto Project is also architecturally agnostic - supporting all major embedded architectures: ARM, 32- and 64-bit x86, PowerPC, and MIPS.<br />
<br />
<br />
The Yocto Project shares the core build tool (BitBake) and metadata syntax with OpenEmbedded, particularly the core set of components known as openembedded-core. This commonality provides automatic familiarity for developers already using OpenEmbedded. However, the learning curve for getting started with the Yocto Project is less steep. It is easier for new users to create a working distribution with the Yocto Project, and more work is being done currently on this subject with the new Hob graphical user interface.<br />
<br />
<br />
When a distribution is created with the Yocto Project, the build tool creates an application development SDK tailored to that distribution. This SDK can plug into the Eclipse IDE or it can be run as a command-line development system, complete with cross tools for the host and development tools for the device being developed.<br />
<br />
<br />
<br />
==== How does the existing embedded workflow compare to the Yocto Project and where can embedded developers save time? ====<br />
<br />
Existing embedded developers have many systems from which to choose. Once a system is chosen and a device's OS has been created, it can often be very difficult and time consuming to trim the distribution to an appropriate footprint size and assemble a working set of components. Then, for the developer’s next project, if updated components are needed, perhaps for bug fixes, security fixes, or new hardware support, the developer typically must start over, with little ability to re-use prior work on distributions. The Yocto Project solves these problems by providing a single focus for embedded development, requiring less time to get a working and up-to-date distribution together. In addition, if commercial support is desired, it is quite simple to transition to a supporting operating system vendor (OSV) who offers products and services compatible with the Yocto Project. All of the major embedded Linux OSVs are active members of the Yocto Project.<br />
<br />
<br />
<br />
==== Does the Yocto Project have a special governance model, or is it managed as an open source project? ====<br />
<br />
The Yocto Project is governed as an open source project working group under the auspices of the Linux Foundation. The Yocto Project Advisory Board consists of representatives from the major sponsoring organizations. This group advises the project on direction and provides resources, but all decisions are made by the project's Maintainers. In addition, there are Interest Groups who drive project feature requirements and provide direction on various aspects of project governance, including finances and infrastructure, and an Architect who coordinates the work of the Maintainers and sets project direction under the guidance of the Advisory Board and its subgroups.<br />
<br />
<br />
<br />
==== Why not just call this project Poky? What has changed between Poky and the Yocto Project? ====<br />
<br />
The Yocto Project is an umbrella project. Accordingly, it includes a number of projects and resources specifically intended for facilitating development with Linux on embedded devices, and it is an appropriate place for larger organizations to collaborate on the development of build infrastructure for embedded Linux. Poky is one of the the largest components of the Yocto Project, and Poky continues as an independent, open source project developing the build system used by the Yocto Project, as well as by other open source projects. <br />
<br />
Poky is a reference system for the Yocto Project, showing how the tools work together. It includes BitBake, openembedded-core, and several other components that anyone can use to start developing with embedded Linux. Poky as a build system is tested by the Yocto Project teams before each release. When you download and use the Yocto Project build system, you are actually downloading Poky and using it to create a distribution that by default is also named Poky. (You can, of course, name your distribution anything you like.)<br />
<br />
<br />
<br />
==== What is the difference between OpenEmbedded and the Yocto Project? ====<br />
<br />
The Yocto Project and OpenEmbedded share a core collection of metadata called openembedded-core. However, the two organizations remain separate, each with its own focus. OpenEmbedded provides a comprehensive set of metadata for a wide variety of architectures, features, and applications. The Yocto Project focuses on providing powerful, easy-to-use, interoperable, well-tested tools, metadata, and board support packages (BSPs) for a core set of architectures and specific boards. <br />
<br />
<br />
=== Release And Support ===<br />
<br />
==== What is the release cycle of the Yocto Project? ====<br />
<br />
Each release of the Yocto Project is subject to its own release schedule according to the community-maintained [https://wiki.yoctoproject.org/wiki/Planning#Yocto Project Planning Guide]. It is generally expected that a new version of the Yocto Project will be released every six months.<br />
<br />
<br />
<br />
==== What is the overall support plan for the Yocto Project? ====<br />
<br />
Security patches and critical bug fixes are supplied one release back. No toolchain or kernel changes are allowed for these updates. Support for longer periods of time can be supplied by commercial OSVs.<br />
<br />
<br />
<br />
=== Technical ===<br />
<br />
==== Who defines the root filesystem and metadata? ====<br />
<br />
Metadata represents the versions of the various components in a distribution, such as the particular versions of the Linux kernel or libraries. The project supplies an example set of metadata that can generate several example distributions. The actual metadata used for the construction of a custom distribution may be supplied by a commercial vendor or created by an embedded developer. The root filesystem is defined in the metadata for a given build of a distribution.<br />
<br />
<br />
<br />
==== What are the criteria for baseline metadata? ====<br />
<br />
The project has selected several major embedded architectures (32- and 64-bit x86, ARM, MIPS, and PowerPC) and footprint sizes (minimal, sato, lsb). Metadata has been created that generates a working build for these architectures and footprints while providing up-to-date and modern versions of the various open source components. We also supply metadata for a number of other components ("world"), which can be pulled into a custom distribution.<br />
<br />
<br />
<br />
==== What tool sets are included in the Yocto Project? When will they be available? ====<br />
<br />
The development toolchain is based on GCC. However, if a project contributor wished to add metadata that uses another toolchain, the project would be happy to consider it.<br />
<br />
<br />
<br />
==== What about graphics drivers? Will they be validated and integrated? ====<br />
<br />
Yes.<br />
<br />
<br />
<br />
==== How will graphics IP in GPL drivers be handled? ====<br />
<br />
The Board Support Packages (BSPs) supplied in the open source project are generally focused on open source code. <br />
<br />
<br />
<br />
==== Where do BSPs come from? Who creates them? What if they need to include proprietary information? ====<br />
<br />
A small set of example BSPs has been created and is maintained for our supported architectures. Commercial Linux vendors, OSVs, silicon suppliers, and board vendors may supply their own BSPs. Proprietary information can be delivered in a BSP, and its distribution is handled by the supplier.<br />
<br />
<br />
<br />
==== Are there tools that allow the removal of a package from the build? ====<br />
<br />
Yes. The recipe for a given distribution can be modified to remove a package. An end developer may add or remove packages from the specified path in the build process. This allows for a completely customized Linux distribution.<br />
<br />
<br />
<br />
==== How can one view the dependencies of packages and the resulting growth in code size as packages are added? ====<br />
<br />
There are tools within BitBake that enable this level of examination.<br />
<br />
“bitbake -g targetname” creates depends.dot and task-depends.dot files in the current directory. These files show which packages and tasks depend on which other packages and tasks and are useful for debugging purposes. <br />
<br />
"bitbake -g -u depexp targetname" shows results in a more human-readable, GUI style. A simple mount of the resulting root image will show how much storage space is being used.<br />
<br />
In addition, the Hob is a new graphical user interface for BitBake that makes these tools much easier to use. <br />
<br />
<br />
<br />
==== What is the path for upgrading just drivers, or for upgrading drivers and related updates to the kernel? ====<br />
<br />
For a given 6-month release of the Yocto Project, the version of the kernel is frozen 6 weeks before release. <br />
<br />
<br />
<br />
==== How often is the kernel updated? How will we know what version of the kernel is used in any particular Yocto Project release? ====<br />
<br />
Given the release cycle for the kernel, every 6-month release of the Yocto Project usually has a new kernel. Specific announcements are made on the Yocto Project mailing list and blogs. In addition, the release notes for any release contains specific information about which kernel is included with that release.<br />
<br />
<br />
<br />
==== Is the kernel included in the Yocto Project? ====<br />
<br />
Metadata referring to a particular kernel version is provided in Yocto Project releases. Of course, patches to the kernel (as with any of the source code in the project) can be applied by the developer. The Yocto Project’s kernel patching system is based on "git" and looks for patches in a Git branch.<br />
<br />
<br />
<br />
==== What are some possible debugging targets? ====<br />
<br />
QEMU is the target for emulation. Several actual hardware targets are also supported, as well as software emulators for various hardware models as provided by silicon vendors.<br />
<br />
<br />
<br />
==== What is meant by automated test capability? ====<br />
<br />
The Yocto Project includes a standard framework for testing on target devices. This allows many existing tests to be reused across projects, reducing rework.<br />
<br />
<br />
<br />
==== If a customer wants a commercial distribution of the Yocto Project, are there potential candidates for productization and commercial distribution? ====<br />
<br />
Yes, all major commercial OSVs currently participate in the Yocto Project.<br />
<br />
<br />
<br />
==== For which software development boards is the Yocto Project validated? ====<br />
<br />
Version 1.1 was validated against:<br />
* ARM Beagleboard C4 and xM<br />
* Several Intel Atom SoCs<br />
* PowerPC - fsl-mpc8315e-rdb<br />
* MIPS - Ubiquity Networks Router Station Pro<br />
<br />
<br />
<br />
==== Is user interface development possible with the Yocto Project? ====<br />
<br />
User Interface development is supported with the Yocto Project. The distribution resulting from a Yocto Project build is just like any other Linux distribution. Developers may build graphical interfaces using frameworks such as Qt, Clutter, or GTK+, all of which are included.<br />
<br />
<br />
<br />
==== Is the Yocto Project a project or a product? How much customer effort is required to productize the Yocto Project? ====<br />
<br />
The Yocto Project is an open source project with support provided by the open source community. Products can be created by OSVs who use the Yocto Project as their upstream or by customers who create their own “roll your own” Linux products from the Yocto Project.<br />
<br />
==== What are the Yocto ADT and Yocto SDK and how do they relate? ====<br />
<br />
The Yocto Project provides support for target-device software developers. The SDK (software developement kit) can be created using ''bitbake <image> -c populate_sdk'', which builds the cross-toolchain and produces an installer in the build/tmp/deploy/sdk directory. This installer contains the image's rootfs and environment setup scripts that are needed for cross-developement. The ADT (application developper tools) are based on the SDK (i.e. architecture-specific cross-toolchain and matching sysroot), but when talking about the ADT we also mean the Eclipse Yocto Plug-in, the Quick EMUlator (QEMU, which lets you simulate target hardware) and various user-space tools (e.g. for application profiling or latency measurements).<br />
<br />
== Usage FAQs ==<br />
<br />
==== How can I add a package to my project? ====<br />
<br />
As with any complex system, the real answer is ''it depends'', but of course that is not very helpful. The simplest method for adding a single package to your build is to add a line like this to <code>conf/local.conf</code>:<br />
<br />
IMAGE_INSTALL_append = " package"<br />
<br />
Use your own package name in place of '''package'''. Note the leading space before the package name. If you want to add multiple packages, you can<br />
use multiple lines like the above, or list all packages on a single line with:<br />
<br />
IMAGE_INSTALL_append = " package1 package2 package3"<br />
<br />
For more information, read [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-addpkg this chapter in the Yocto Project Development Manual].<br />
<br />
==== How can I use my own kernel with my project? ====<br />
<br />
If you just want to change the kernel configuration, you can follow [http://www.yoctoproject.org/docs/current/kernel-manual/kernel-manual.html#kernel-configuration these instructions] to edit the stock kernel's configuration using <code>make menuconfig</code>.<br />
<br />
If you have a separate kernel you wish to use, the simplest method for adding a new kernel to your build is to create a recipe for it and then add a line like this to <code>conf/local.conf</code>:<br />
<br />
PREFERRED_PROVIDER_virtual/kernel = "<i>your-recipe-for-kernel</i>"<br />
<br />
You can find several kernel examples in the Yocto Project file's meta/recipes-kernel/linux directory that you can use as references. [http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#platdev-newmachine-kernel Look here] for more information.<br />
<br />
==== Who may I contact for further questions regarding the Yocto Project? ====<br />
<br />
For any additional questions, please contact [mailto:jeffrey.osier-mixon@intel.com Jeff Osier-Mixon], the Yocto Project Community Manager.</div>Dennis Meierhttps://wiki.yoctoproject.org/wiki/index.php?title=Poky-Tiny&diff=11706Poky-Tiny2013-12-05T08:37:22Z<p>Dennis Meier: /* Controlling busybox features */</p>
<hr />
<div>Poky-tiny is a variant of the poky distribution which is stripped down to minimal configuration.<br />
<br />
== Introduction ==<br />
It is intended to be useful for a few different purposes:<br />
* as a demonstration of techniques useful for reducing other images<br />
* as a springboard for very low-end distributions and images<br />
* as a place to experiment with whole-system optimization techniques<br />
<br />
It was written by Darren Hart.<br />
<br />
=== Basic use ===<br />
To use the poky-tiny distro, adjust the DISTRO setting in your conf/local.conf file.<br />
That is, set it to: "DISTRO=poky-tiny"<br />
<br />
poky-tiny does not include a target-side package manager, so it is useful, to avoid<br />
extra dependencies, to use it with the IPKG package management scheme. This is the lightest-weight<br />
package management scheme. Set this in your conf/local.conf file:<br />
PACKAGE_CLASSES ?= "package_ipk"<br />
<br />
Then do a basic build of the system:<br />
$ bitbake core-image-minimal<br />
<br />
Resulting images should appear in your <build-dir>/tmp/deploy/images directory.<br />
<br />
== FAQ ==<br />
* where is poky-tiny defined?<br />
** poky-tiny is defined in <yocto-dir>/meta-yocto/conf/distro/poky-tiny.conf. Some other recipes and images have been modified to support the features in poky-tiny.<br />
** The kernel recipe for poky-tiny is in <yocto-dir>/meta/recipes-kernel/linux/linux-yocto-tiny_x.x.bb<br />
* What images are supported?<br />
** As of poky-danny-8.0 (the 1.3 release of yocto), poky-tiny.conf defined the following images: IMAGE_FSTYPES = "ext2 cpio.gz" This means it will build both an ext2 filesystem image, and a cpio.gz image (suitable for use as an initramfs).<br />
* What machines are supported (are there any restrictions)?<br />
** in the kernel recipe file, it has COMPATIBLE_MACHINE="(qemux86)"<br />
* What features have been eliminated?<br />
* What is the size difference between poky-tiny and poky (core-image-minimal)?<br />
* Are there differences in the way poky-tiny is customized, from the way default 'poky' is customized? (eg. gotchas for adding to IMAGE_INSTALL or IMAGE_FEATURES)?<br />
<br />
== Creating your own tiny-based distro ==<br />
You can create your own distro, based on the tiny work, by copying the poky-tiny.conf file<br />
to your own layer, and editing it from there.<br />
<br />
Assuming you are calling your layer 'meta-foo', you could do the following:<br />
<br />
* create your meta-foo layer (see other docs for this)<br />
* copy the poky-tiny distro configuration file to your own layer<br />
$ install -p meta-foo/conf/distro<br />
$ cp meta-yocto/conf/distro/poky-tiny.conf meta-foo/conf/distro/foo-tiny.conf<br />
* edit your conf/local.conf to use your foo-tiny.conf distro<br />
$ vi <build-dir>/conf/local.conf<br />
[change it so "DISTRO?=foo-tiny"]<br />
<br />
== Adjusting poky-tiny ==<br />
=== Controlling LIBC features ===<br />
Inside foo-tiny.conf (derived from poky-tiny.conf), you can specify what LIBC features to support<br />
by modifying the DISTRO_FEATURES_LIBC variable.<br />
<br />
This variable is declared to be a space-separated list of other DISTRO_FEATURES_LIBC_xxx variables.<br />
To turn on or off features in libc, edit the values of these variables.<br />
<br />
==== eglibc ====<br />
To see different options that are available, see the file:<br />
<yocto-dir>/meta/recipes-core/eglibc/eglibc-options.inc<br />
<br />
Listed in that file are the routines: distro_features_check_deps() and features_to_eglibc_settings(),<br />
which map items listed in DISTRO_FEATURES_LIBC into specific eglibc settings.<br />
<br />
==== uclibc ====<br />
To see different options that are available, see the file:<br />
<yocto-dir>/meta/recipes-core/uclibc/uclibc-config.inc<br />
<br />
Listed in that file is the routine: features_to_uclibc_settings(),<br />
which maps items listed in DISTRO_FEATURES_LIBC into specific uclibc settings.<br />
<br />
=== Controlling kernel features ===<br />
<br />
=== Controlling busybox features ===<br />
To adjust busybox features, it's necessary to have your own defconfig. Then the busybox recipe must be appended (or you need your own busybox recipe) to tell bitbake where it can find this defconfig. An example: <br />
<br />
'''$ cd /path/to/poky/directory/meta-new-layer'''<br />
'''$ tree recipes-core/'''<br />
recipes-core/<br />
├── busybox_1.20.2<br />
│ └── defconfig<br />
└── busybox_1.20.2.bbappend<br />
1 directory, 2 files<br />
'''$ cat recipes-core/busybox_1.20.2.bbappend''' <br />
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br />
PACKAGES =+ "${PN}-mdev"<br />
'''$ diff recipes-core/busybox_1.20.2/defconfig ../meta/recipes-core/busybox/busybox-1.20.2/defconfig''' <br />
530d529<br />
< CONFIG_MDEV=y<br />
536d534<br />
< CONFIG_FEATURE_MDEV_LOAD_FIRMWARE=y<br />
<br />
In this example you can see how in a new layer, the busybox_<version>.bbappend file modifies the FILESEXTRAPATHS, which enables bitbake to find the corresponding defconfig in meta-new-layer/recipes-core/busybox_1.20.2. In the example defconfig, mdev gets enabled by setting the variables CONFIG_MDEV and CONFIG_FEATURE_MDEV_LOAD_FIRMWARE. The original defconfig that would be used by poky normally is stored in meta/recipes-core/busybox/busybox-<version>/defconfig as of this writing. PACKAGES += just makes sure that busybox-mdev gets packaged because it doesn't do this by default.<br />
<br />
In general: Set the FILESEXTRAPATHS so bitbake finds your defconfig and put whatever you like into your defconfig.<br />
<br />
== Troubleshooting the build ==<br />
<br />
== Invoking qemu with poky-tiny images ==<br />
Runqemu doesn't understand poky-tiny (or initramfs?). Try executing qemu directly instead. Here's the template:<br />
<br />
$ qemu-system-i386 -kernel path/to/kernel -initrd path/to/image.cpio.gz -nographic -append "console=ttyS0 root=/dev/ram0"<br />
<br />
Here the actual full command I used:<br />
<br />
$ tmp/sysroots/x86_64-linux/usr/bin/qemu-system-i386 -kernel tmp/deploy/images/bzImage-qemux86.bin -initrd tmp/deploy/images/core-image-minimal-qemux86.cpio.gz -nographic -append "console=ttyS0 root=/dev/ram0"<br />
<br />
=== Some information about the running system ===<br />
You can poke around, and see the status of various things. 'ps' shows only 22 processes running, with only 3 user-space (ie not kernel threads):<br />
<br />
# ps | grep -v [[]<br />
PID USER VSZ STAT COMMAND<br />
1 root 2004 S {init} /bin/sh /init<br />
38 root 2144 S sh<br />
41 root 2144 R ps<br />
<br />
So... busybox is really the only executable on the system, and it is providing /bin/sh. /init is a shell script,<br />
which will run /etc/rc.local, if one is present. There's a sample in /etc/rc.local.sample that you can use as a<br />
starting point to customize the init process. If you turn on packages in yocto, there will be init scripts deposited<br />
in /etc/init.d, which you can call from either /init or /etc/rc.local to invoke (none of that fancy sysV rc init scripts here!)<br />
<br />
I booted with mem=24M (that was about as small as I could go) and saw the following memory utilization:<br />
# free<br />
total used free shared buffers<br />
Mem: 19724 5944 13780 0 0<br />
-/+ buffers: 5944 13780<br />
Swap: 0 0 0<br />
<br />
The filesystem is a little over 3M in size:<br />
# du -sh /<br />
3.2M /<br />
<br />
Here's a sample of what the filesystem looks like (as of yocto-danny-8.0), with results sorted by size<br />
and /sys, /proc and /dev omitted:<br />
# find / -type f -xdev | xargs ls -laSr<br />
-rw-r--r-- 1 root root 0 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.dep<br />
-rw-r--r-- 1 root root 0 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.builtin.bin<br />
-rw-r--r-- 1 root root 0 Nov 14 00:45 /etc/network/nm-disabled-eth0<br />
-rw-r--r-- 1 root root 0 Nov 14 00:45 /etc/motd<br />
-rw-r--r-- 1 root root 0 Nov 14 00:14 /etc/ld.so.conf<br />
-rw-r--r-- 1 root root 0 Nov 14 00:45 /etc/default/usbd<br />
-rw-r--r-- 1 root root 6 Nov 14 22:05 /var/volatile/run/ifstate<br />
-rw-r--r-- 1 root root 8 Nov 14 00:45 /etc/hostname<br />
-rw-r--r-- 1 root root 12 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.symbols.bin<br />
-rw-r--r-- 1 root root 12 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.dep.bin<br />
-rw-r--r-- 1 root root 12 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.alias.bin<br />
-rw-r--r-- 1 root root 13 Nov 14 21:24 /etc/version<br />
-rw-r--r-- 1 root root 13 Nov 14 21:24 /etc/timestamp<br />
-rw-r--r-- 1 root root 26 Nov 14 00:45 /etc/host.conf<br />
-rw-r--r-- 1 root root 38 Nov 14 00:45 /etc/filesystems<br />
-rw-r--r-- 1 root root 44 Nov 14 00:45 /etc/hosts<br />
-rw-r--r-- 1 root root 45 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.alias<br />
-rwxr-xr-x 1 root root 49 Nov 14 00:22 /usr/share/udhcpc/default.script<br />
-rw-r--r-- 1 root root 49 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.symbols<br />
-rw-r--r-- 1 root root 52 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.devname<br />
-rw-r--r-- 1 root root 72 Nov 14 00:45 /etc/issue.net<br />
-rw-r--r-- 1 root root 74 Nov 14 00:45 /etc/issue<br />
-rwxr-xr-x 1 root root 93 Nov 13 20:19 /etc/default/devpts<br />
-rw-r--r-- 1 root root 109 Nov 14 00:45 /etc/shells<br />
-rw-r--r-- 1 root root 131 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.softdep<br />
-rw-r--r-- 1 root root 132 Nov 14 00:45 /etc/network/interfaces<br />
-rwxr-xr-x 1 root root 152 Nov 14 00:45 /etc/skel/.profile<br />
-rwxr-xr-x 1 root root 270 Nov 13 20:19 /etc/init.d/hostname.sh<br />
-rwxr-xr-x 1 root root 289 Nov 13 20:19 /etc/init.d/reboot<br />
-rwxr-xr-x 1 root root 321 Nov 13 20:19 /etc/init.d/save-rtc.sh<br />
-rwxr-xr-x 1 root root 410 Nov 14 00:45 /etc/skel/.bashrc<br />
-rwxr-xr-x 1 root root 438 Nov 13 20:19 /etc/init.d/sendsigs<br />
-rw-r--r-- 1 root root 446 Nov 14 21:23 /etc/group<br />
-rw-r--r-- 1 root root 465 Nov 14 00:45 /etc/nsswitch.conf<br />
-rwxr-xr-x 1 root root 473 Nov 14 21:24 /init<br />
-rwxr-xr-x 1 root root 492 Nov 13 20:19 /etc/init.d/banner.sh<br />
-rwxr-xr-x 1 root root 510 Nov 13 20:19 /etc/init.d/halt<br />
-rwxr-xr-x 1 root root 516 Nov 13 20:19 /etc/init.d/umountfs<br />
-rwxr-xr-x 1 root root 526 Nov 13 20:19 /etc/init.d/devpts.sh<br />
-rwxr-xr-x 1 root root 578 Nov 13 20:19 /etc/init.d/single<br />
-rwxr-xr-x 1 root root 585 Nov 13 20:19 /etc/init.d/rmnologin.sh<br />
-rw-r--r-- 1 root root 586 Nov 14 00:20 /usr/share/run-postinsts/run-postinsts.awk<br />
-rwxr-xr-x 1 root root 609 Nov 14 00:20 /etc/init.d/run-postinsts<br />
-rwxr-xr-x 1 root root 632 Nov 14 00:45 /etc/rc.local.sample<br />
-rw-r--r-- 1 root root 651 Nov 14 00:22 /etc/syslog-startup.conf.busybox<br />
-rwxr-xr-x 1 root root 660 Nov 13 20:19 /etc/init.d/sysfs.sh<br />
-rw-r--r-- 1 root root 704 Nov 14 00:45 /etc/fstab<br />
-rwxr-xr-x 1 root root 711 Nov 13 20:19 /etc/init.d/umountnfs.sh<br />
-rw-r--r-- 1 root root 719 Nov 14 21:23 /etc/passwd<br />
-rw------- 1 root root 737 Nov 14 22:22 /.ash_history<br />
-rw-r--r-- 1 root root 783 Nov 14 21:24 /etc/ld.so.cache<br />
-rwxr-xr-x 1 root root 809 Nov 14 00:45 /etc/network/if-pre-up.d/nfsroot<br />
-rw------- 1 root root 836 Nov 14 21:24 /var/volatile/cache/ldconfig/aux-cache<br />
-rw-r--r-- 1 root root 847 Nov 14 00:45 /etc/profile<br />
-rwxr-xr-x 1 root root 859 Nov 13 20:19 /etc/init.d/mountall.sh<br />
-rwxr-xr-x 1 root root 878 Nov 14 00:45 /etc/init.d/modutils.sh<br />
-rw-r--r-- 1 root root 887 Nov 14 00:45 /etc/rpc<br />
-rw-r--r-- 1 root root 1123 Nov 13 20:19 /etc/init.d/functions.initscripts<br />
-rwxr-xr-x 1 root root 1349 Nov 13 20:19 /etc/init.d/urandom<br />
-rwxr-xr-x 1 root root 1540 Nov 13 20:19 /etc/init.d/mountnfs.sh<br />
-rw-r--r-- 1 root root 1633 Nov 14 00:45 /etc/inputrc<br />
-rwxr-xr-x 1 root root 1711 Nov 14 00:22 /etc/init.d/syslog.busybox<br />
-rw-r--r-- 1 root root 1740 Nov 13 20:19 /etc/default/volatiles/00_core<br />
-rwxr-xr-x 1 root root 1752 Nov 13 20:19 /etc/init.d/bootmisc.sh<br />
-rwxr-xr-x 1 root root 1909 Nov 14 00:45 /etc/init.d/networking<br />
-rw-r--r-- 1 root root 2146 Nov 14 00:22 /etc/busybox.links<br />
-rwxr-xr-x 1 root root 2514 Nov 14 00:22 /etc/init.d/hwclock.sh<br />
-rwxr-xr-x 1 root root 2548 Nov 14 00:22 /etc/udhcpc.d/50default<br />
-rw-r--r-- 1 root root 2933 Nov 14 00:45 /etc/protocols<br />
-rwxr-xr-x 1 root root 3229 Nov 13 20:19 /etc/init.d/checkroot.sh<br />
-rwxr-xr-x 1 root root 4409 Nov 13 20:16 /usr/sbin/update-rc.d<br />
-rwxr-xr-x 1 root root 4524 Nov 14 00:45 /usr/bin/update-alternatives<br />
-rwxr-xr-x 1 root root 5249 Nov 13 20:19 /etc/init.d/populate-volatile.sh<br />
-rwxr-xr-x 1 root root 6666 Nov 13 20:19 /etc/device_table<br />
-rwsr-xr-x 1 root root 9544 Nov 14 00:14 /usr/lib/eglibc/pt_chown<br />
-rwxr-xr-x 1 root root 9740 Nov 14 00:14 /lib/libutil-2.16.so<br />
-rwxr-xr-x 1 root root 13828 Nov 14 00:14 /lib/libdl-2.16.so<br />
-rw-r--r-- 1 root root 19398 Nov 14 00:45 /etc/services<br />
-rwxr-xr-x 1 root root 22020 Nov 14 00:14 /lib/libnss_dns-2.16.so<br />
-rwxr-xr-x 1 root root 26064 Nov 14 00:14 /lib/libcrypt-2.16.so<br />
-rwxr-xr-x 1 root root 30624 Nov 14 00:14 /lib/librt-2.16.so<br />
-rwxr-xr-x 1 root root 34588 Nov 14 00:14 /lib/libnss_compat-2.16.so<br />
-rwxr-xr-x 1 root root 46980 Nov 14 00:14 /lib/libnss_files-2.16.so<br />
-rwxr-xr-x 1 root root 83716 Nov 14 00:14 /lib/libresolv-2.16.so<br />
-rwxr-xr-x 1 root root 87860 Nov 14 00:14 /lib/libnsl-2.16.so<br />
-rwxr-xr-x 1 root root 96128 Nov 14 00:14 /lib/libpthread-2.16.so<br />
-rwxr-xr-x 1 root root 127228 Nov 14 00:14 /lib/ld-2.16.so<br />
-rwxr-xr-x 1 root root 251328 Nov 14 00:14 /lib/libm-2.16.so<br />
-rwxr-xr-x 1 root root 524924 Nov 14 00:14 /sbin/ldconfig<br />
-rwsr-xr-x 1 root root 554820 Nov 14 00:22 /bin/busybox<br />
-rwxr-xr-x 1 root root 1056128 Nov 14 00:14 /lib/libc-2.16.so<br />
<br />
busybox, ldconfig and libc (and other libc-related libs) make up about 95% of the system.<br />
<br />
If busybox were statically linked, and ldconfig and libc were omitted, I believe it would<br />
reduce the size of the system substantially.<br />
<br />
=== exiting the system ===<br />
There is no 'shutdown' command, but you can use 'ctrl-a to execute a command to the qemu monitor, and 'ctrl-a b' to issue a sysrq to the Linux kernel.<br />
You can do a sysrq-B to do a reboot. Do: ctrl-a h to see available commands, and ctrl-a x to exit qemu.<br />
<br />
== Resources ==<br />
* Presentation: [http://elinux.org/images/2/2b/Elce11_hart.pdf Tuning Linux For Embedded Systems: When Less Is More] by Darren Hart, ELC Europe 2011, October 2011, Prague, Czech Republic</div>Dennis Meierhttps://wiki.yoctoproject.org/wiki/index.php?title=Poky-Tiny&diff=11705Poky-Tiny2013-12-05T08:34:08Z<p>Dennis Meier: /* Controlling busybox features */</p>
<hr />
<div>Poky-tiny is a variant of the poky distribution which is stripped down to minimal configuration.<br />
<br />
== Introduction ==<br />
It is intended to be useful for a few different purposes:<br />
* as a demonstration of techniques useful for reducing other images<br />
* as a springboard for very low-end distributions and images<br />
* as a place to experiment with whole-system optimization techniques<br />
<br />
It was written by Darren Hart.<br />
<br />
=== Basic use ===<br />
To use the poky-tiny distro, adjust the DISTRO setting in your conf/local.conf file.<br />
That is, set it to: "DISTRO=poky-tiny"<br />
<br />
poky-tiny does not include a target-side package manager, so it is useful, to avoid<br />
extra dependencies, to use it with the IPKG package management scheme. This is the lightest-weight<br />
package management scheme. Set this in your conf/local.conf file:<br />
PACKAGE_CLASSES ?= "package_ipk"<br />
<br />
Then do a basic build of the system:<br />
$ bitbake core-image-minimal<br />
<br />
Resulting images should appear in your <build-dir>/tmp/deploy/images directory.<br />
<br />
== FAQ ==<br />
* where is poky-tiny defined?<br />
** poky-tiny is defined in <yocto-dir>/meta-yocto/conf/distro/poky-tiny.conf. Some other recipes and images have been modified to support the features in poky-tiny.<br />
** The kernel recipe for poky-tiny is in <yocto-dir>/meta/recipes-kernel/linux/linux-yocto-tiny_x.x.bb<br />
* What images are supported?<br />
** As of poky-danny-8.0 (the 1.3 release of yocto), poky-tiny.conf defined the following images: IMAGE_FSTYPES = "ext2 cpio.gz" This means it will build both an ext2 filesystem image, and a cpio.gz image (suitable for use as an initramfs).<br />
* What machines are supported (are there any restrictions)?<br />
** in the kernel recipe file, it has COMPATIBLE_MACHINE="(qemux86)"<br />
* What features have been eliminated?<br />
* What is the size difference between poky-tiny and poky (core-image-minimal)?<br />
* Are there differences in the way poky-tiny is customized, from the way default 'poky' is customized? (eg. gotchas for adding to IMAGE_INSTALL or IMAGE_FEATURES)?<br />
<br />
== Creating your own tiny-based distro ==<br />
You can create your own distro, based on the tiny work, by copying the poky-tiny.conf file<br />
to your own layer, and editing it from there.<br />
<br />
Assuming you are calling your layer 'meta-foo', you could do the following:<br />
<br />
* create your meta-foo layer (see other docs for this)<br />
* copy the poky-tiny distro configuration file to your own layer<br />
$ install -p meta-foo/conf/distro<br />
$ cp meta-yocto/conf/distro/poky-tiny.conf meta-foo/conf/distro/foo-tiny.conf<br />
* edit your conf/local.conf to use your foo-tiny.conf distro<br />
$ vi <build-dir>/conf/local.conf<br />
[change it so "DISTRO?=foo-tiny"]<br />
<br />
== Adjusting poky-tiny ==<br />
=== Controlling LIBC features ===<br />
Inside foo-tiny.conf (derived from poky-tiny.conf), you can specify what LIBC features to support<br />
by modifying the DISTRO_FEATURES_LIBC variable.<br />
<br />
This variable is declared to be a space-separated list of other DISTRO_FEATURES_LIBC_xxx variables.<br />
To turn on or off features in libc, edit the values of these variables.<br />
<br />
==== eglibc ====<br />
To see different options that are available, see the file:<br />
<yocto-dir>/meta/recipes-core/eglibc/eglibc-options.inc<br />
<br />
Listed in that file are the routines: distro_features_check_deps() and features_to_eglibc_settings(),<br />
which map items listed in DISTRO_FEATURES_LIBC into specific eglibc settings.<br />
<br />
==== uclibc ====<br />
To see different options that are available, see the file:<br />
<yocto-dir>/meta/recipes-core/uclibc/uclibc-config.inc<br />
<br />
Listed in that file is the routine: features_to_uclibc_settings(),<br />
which maps items listed in DISTRO_FEATURES_LIBC into specific uclibc settings.<br />
<br />
=== Controlling kernel features ===<br />
<br />
=== Controlling busybox features ===<br />
To adjust busybox features, it's necessary to have your own defconfig. Then the busybox recipe must be appended (or you need your own busybox recipe) to tell bitbake where it can find this defconfig. An example: <br />
<br />
'''$ cd /path/to/poky/directory/meta-new-layer'''<br />
'''$ tree recipes-core/'''<br />
recipes-core/<br />
├── busybox_1.20.2<br />
│ └── defconfig<br />
└── busybox_1.20.2.bbappend<br />
1 directory, 2 files<br />
'''$ cat recipes-core/busybox_1.20.2.bbappend''' <br />
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br />
PACKAGES =+ "${PN}-mdev"<br />
'''$ diff recipes-core/busybox_1.20.2/defconfig ../meta/recipes-core/busybox/busybox-1.20.2/defconfig''' <br />
530d529<br />
< CONFIG_MDEV=y<br />
536d534<br />
< CONFIG_FEATURE_MDEV_LOAD_FIRMWARE=y<br />
<br />
In this example you can see how in a new layer, the busybox_<version>.bbappend file modifies the FILESEXTRAPATHS, which enables bitbake to find the corresponding defconfig in meta-new-layer/recipes-core/busybox_1.20.2. In the example defconfig, mdev gets enabled by setting the variables CONFIG_MDEV and CONFIG_FEATURE_MDEV_LOAD_FIRMWARE. The original defconfig that would be used by poky normally is stored in meta/recipes-core/busybox/busybox-<version>/defconfig as of this writing. PACKAGES += just makes sure that busybox-mdev gets packaged because it doesn't do this by default.<br />
<br />
== Troubleshooting the build ==<br />
<br />
== Invoking qemu with poky-tiny images ==<br />
Runqemu doesn't understand poky-tiny (or initramfs?). Try executing qemu directly instead. Here's the template:<br />
<br />
$ qemu-system-i386 -kernel path/to/kernel -initrd path/to/image.cpio.gz -nographic -append "console=ttyS0 root=/dev/ram0"<br />
<br />
Here the actual full command I used:<br />
<br />
$ tmp/sysroots/x86_64-linux/usr/bin/qemu-system-i386 -kernel tmp/deploy/images/bzImage-qemux86.bin -initrd tmp/deploy/images/core-image-minimal-qemux86.cpio.gz -nographic -append "console=ttyS0 root=/dev/ram0"<br />
<br />
=== Some information about the running system ===<br />
You can poke around, and see the status of various things. 'ps' shows only 22 processes running, with only 3 user-space (ie not kernel threads):<br />
<br />
# ps | grep -v [[]<br />
PID USER VSZ STAT COMMAND<br />
1 root 2004 S {init} /bin/sh /init<br />
38 root 2144 S sh<br />
41 root 2144 R ps<br />
<br />
So... busybox is really the only executable on the system, and it is providing /bin/sh. /init is a shell script,<br />
which will run /etc/rc.local, if one is present. There's a sample in /etc/rc.local.sample that you can use as a<br />
starting point to customize the init process. If you turn on packages in yocto, there will be init scripts deposited<br />
in /etc/init.d, which you can call from either /init or /etc/rc.local to invoke (none of that fancy sysV rc init scripts here!)<br />
<br />
I booted with mem=24M (that was about as small as I could go) and saw the following memory utilization:<br />
# free<br />
total used free shared buffers<br />
Mem: 19724 5944 13780 0 0<br />
-/+ buffers: 5944 13780<br />
Swap: 0 0 0<br />
<br />
The filesystem is a little over 3M in size:<br />
# du -sh /<br />
3.2M /<br />
<br />
Here's a sample of what the filesystem looks like (as of yocto-danny-8.0), with results sorted by size<br />
and /sys, /proc and /dev omitted:<br />
# find / -type f -xdev | xargs ls -laSr<br />
-rw-r--r-- 1 root root 0 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.dep<br />
-rw-r--r-- 1 root root 0 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.builtin.bin<br />
-rw-r--r-- 1 root root 0 Nov 14 00:45 /etc/network/nm-disabled-eth0<br />
-rw-r--r-- 1 root root 0 Nov 14 00:45 /etc/motd<br />
-rw-r--r-- 1 root root 0 Nov 14 00:14 /etc/ld.so.conf<br />
-rw-r--r-- 1 root root 0 Nov 14 00:45 /etc/default/usbd<br />
-rw-r--r-- 1 root root 6 Nov 14 22:05 /var/volatile/run/ifstate<br />
-rw-r--r-- 1 root root 8 Nov 14 00:45 /etc/hostname<br />
-rw-r--r-- 1 root root 12 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.symbols.bin<br />
-rw-r--r-- 1 root root 12 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.dep.bin<br />
-rw-r--r-- 1 root root 12 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.alias.bin<br />
-rw-r--r-- 1 root root 13 Nov 14 21:24 /etc/version<br />
-rw-r--r-- 1 root root 13 Nov 14 21:24 /etc/timestamp<br />
-rw-r--r-- 1 root root 26 Nov 14 00:45 /etc/host.conf<br />
-rw-r--r-- 1 root root 38 Nov 14 00:45 /etc/filesystems<br />
-rw-r--r-- 1 root root 44 Nov 14 00:45 /etc/hosts<br />
-rw-r--r-- 1 root root 45 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.alias<br />
-rwxr-xr-x 1 root root 49 Nov 14 00:22 /usr/share/udhcpc/default.script<br />
-rw-r--r-- 1 root root 49 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.symbols<br />
-rw-r--r-- 1 root root 52 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.devname<br />
-rw-r--r-- 1 root root 72 Nov 14 00:45 /etc/issue.net<br />
-rw-r--r-- 1 root root 74 Nov 14 00:45 /etc/issue<br />
-rwxr-xr-x 1 root root 93 Nov 13 20:19 /etc/default/devpts<br />
-rw-r--r-- 1 root root 109 Nov 14 00:45 /etc/shells<br />
-rw-r--r-- 1 root root 131 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.softdep<br />
-rw-r--r-- 1 root root 132 Nov 14 00:45 /etc/network/interfaces<br />
-rwxr-xr-x 1 root root 152 Nov 14 00:45 /etc/skel/.profile<br />
-rwxr-xr-x 1 root root 270 Nov 13 20:19 /etc/init.d/hostname.sh<br />
-rwxr-xr-x 1 root root 289 Nov 13 20:19 /etc/init.d/reboot<br />
-rwxr-xr-x 1 root root 321 Nov 13 20:19 /etc/init.d/save-rtc.sh<br />
-rwxr-xr-x 1 root root 410 Nov 14 00:45 /etc/skel/.bashrc<br />
-rwxr-xr-x 1 root root 438 Nov 13 20:19 /etc/init.d/sendsigs<br />
-rw-r--r-- 1 root root 446 Nov 14 21:23 /etc/group<br />
-rw-r--r-- 1 root root 465 Nov 14 00:45 /etc/nsswitch.conf<br />
-rwxr-xr-x 1 root root 473 Nov 14 21:24 /init<br />
-rwxr-xr-x 1 root root 492 Nov 13 20:19 /etc/init.d/banner.sh<br />
-rwxr-xr-x 1 root root 510 Nov 13 20:19 /etc/init.d/halt<br />
-rwxr-xr-x 1 root root 516 Nov 13 20:19 /etc/init.d/umountfs<br />
-rwxr-xr-x 1 root root 526 Nov 13 20:19 /etc/init.d/devpts.sh<br />
-rwxr-xr-x 1 root root 578 Nov 13 20:19 /etc/init.d/single<br />
-rwxr-xr-x 1 root root 585 Nov 13 20:19 /etc/init.d/rmnologin.sh<br />
-rw-r--r-- 1 root root 586 Nov 14 00:20 /usr/share/run-postinsts/run-postinsts.awk<br />
-rwxr-xr-x 1 root root 609 Nov 14 00:20 /etc/init.d/run-postinsts<br />
-rwxr-xr-x 1 root root 632 Nov 14 00:45 /etc/rc.local.sample<br />
-rw-r--r-- 1 root root 651 Nov 14 00:22 /etc/syslog-startup.conf.busybox<br />
-rwxr-xr-x 1 root root 660 Nov 13 20:19 /etc/init.d/sysfs.sh<br />
-rw-r--r-- 1 root root 704 Nov 14 00:45 /etc/fstab<br />
-rwxr-xr-x 1 root root 711 Nov 13 20:19 /etc/init.d/umountnfs.sh<br />
-rw-r--r-- 1 root root 719 Nov 14 21:23 /etc/passwd<br />
-rw------- 1 root root 737 Nov 14 22:22 /.ash_history<br />
-rw-r--r-- 1 root root 783 Nov 14 21:24 /etc/ld.so.cache<br />
-rwxr-xr-x 1 root root 809 Nov 14 00:45 /etc/network/if-pre-up.d/nfsroot<br />
-rw------- 1 root root 836 Nov 14 21:24 /var/volatile/cache/ldconfig/aux-cache<br />
-rw-r--r-- 1 root root 847 Nov 14 00:45 /etc/profile<br />
-rwxr-xr-x 1 root root 859 Nov 13 20:19 /etc/init.d/mountall.sh<br />
-rwxr-xr-x 1 root root 878 Nov 14 00:45 /etc/init.d/modutils.sh<br />
-rw-r--r-- 1 root root 887 Nov 14 00:45 /etc/rpc<br />
-rw-r--r-- 1 root root 1123 Nov 13 20:19 /etc/init.d/functions.initscripts<br />
-rwxr-xr-x 1 root root 1349 Nov 13 20:19 /etc/init.d/urandom<br />
-rwxr-xr-x 1 root root 1540 Nov 13 20:19 /etc/init.d/mountnfs.sh<br />
-rw-r--r-- 1 root root 1633 Nov 14 00:45 /etc/inputrc<br />
-rwxr-xr-x 1 root root 1711 Nov 14 00:22 /etc/init.d/syslog.busybox<br />
-rw-r--r-- 1 root root 1740 Nov 13 20:19 /etc/default/volatiles/00_core<br />
-rwxr-xr-x 1 root root 1752 Nov 13 20:19 /etc/init.d/bootmisc.sh<br />
-rwxr-xr-x 1 root root 1909 Nov 14 00:45 /etc/init.d/networking<br />
-rw-r--r-- 1 root root 2146 Nov 14 00:22 /etc/busybox.links<br />
-rwxr-xr-x 1 root root 2514 Nov 14 00:22 /etc/init.d/hwclock.sh<br />
-rwxr-xr-x 1 root root 2548 Nov 14 00:22 /etc/udhcpc.d/50default<br />
-rw-r--r-- 1 root root 2933 Nov 14 00:45 /etc/protocols<br />
-rwxr-xr-x 1 root root 3229 Nov 13 20:19 /etc/init.d/checkroot.sh<br />
-rwxr-xr-x 1 root root 4409 Nov 13 20:16 /usr/sbin/update-rc.d<br />
-rwxr-xr-x 1 root root 4524 Nov 14 00:45 /usr/bin/update-alternatives<br />
-rwxr-xr-x 1 root root 5249 Nov 13 20:19 /etc/init.d/populate-volatile.sh<br />
-rwxr-xr-x 1 root root 6666 Nov 13 20:19 /etc/device_table<br />
-rwsr-xr-x 1 root root 9544 Nov 14 00:14 /usr/lib/eglibc/pt_chown<br />
-rwxr-xr-x 1 root root 9740 Nov 14 00:14 /lib/libutil-2.16.so<br />
-rwxr-xr-x 1 root root 13828 Nov 14 00:14 /lib/libdl-2.16.so<br />
-rw-r--r-- 1 root root 19398 Nov 14 00:45 /etc/services<br />
-rwxr-xr-x 1 root root 22020 Nov 14 00:14 /lib/libnss_dns-2.16.so<br />
-rwxr-xr-x 1 root root 26064 Nov 14 00:14 /lib/libcrypt-2.16.so<br />
-rwxr-xr-x 1 root root 30624 Nov 14 00:14 /lib/librt-2.16.so<br />
-rwxr-xr-x 1 root root 34588 Nov 14 00:14 /lib/libnss_compat-2.16.so<br />
-rwxr-xr-x 1 root root 46980 Nov 14 00:14 /lib/libnss_files-2.16.so<br />
-rwxr-xr-x 1 root root 83716 Nov 14 00:14 /lib/libresolv-2.16.so<br />
-rwxr-xr-x 1 root root 87860 Nov 14 00:14 /lib/libnsl-2.16.so<br />
-rwxr-xr-x 1 root root 96128 Nov 14 00:14 /lib/libpthread-2.16.so<br />
-rwxr-xr-x 1 root root 127228 Nov 14 00:14 /lib/ld-2.16.so<br />
-rwxr-xr-x 1 root root 251328 Nov 14 00:14 /lib/libm-2.16.so<br />
-rwxr-xr-x 1 root root 524924 Nov 14 00:14 /sbin/ldconfig<br />
-rwsr-xr-x 1 root root 554820 Nov 14 00:22 /bin/busybox<br />
-rwxr-xr-x 1 root root 1056128 Nov 14 00:14 /lib/libc-2.16.so<br />
<br />
busybox, ldconfig and libc (and other libc-related libs) make up about 95% of the system.<br />
<br />
If busybox were statically linked, and ldconfig and libc were omitted, I believe it would<br />
reduce the size of the system substantially.<br />
<br />
=== exiting the system ===<br />
There is no 'shutdown' command, but you can use 'ctrl-a to execute a command to the qemu monitor, and 'ctrl-a b' to issue a sysrq to the Linux kernel.<br />
You can do a sysrq-B to do a reboot. Do: ctrl-a h to see available commands, and ctrl-a x to exit qemu.<br />
<br />
== Resources ==<br />
* Presentation: [http://elinux.org/images/2/2b/Elce11_hart.pdf Tuning Linux For Embedded Systems: When Less Is More] by Darren Hart, ELC Europe 2011, October 2011, Prague, Czech Republic</div>Dennis Meierhttps://wiki.yoctoproject.org/wiki/index.php?title=Poky-Tiny&diff=11704Poky-Tiny2013-12-05T08:07:37Z<p>Dennis Meier: /* Controlling busybox features */</p>
<hr />
<div>Poky-tiny is a variant of the poky distribution which is stripped down to minimal configuration.<br />
<br />
== Introduction ==<br />
It is intended to be useful for a few different purposes:<br />
* as a demonstration of techniques useful for reducing other images<br />
* as a springboard for very low-end distributions and images<br />
* as a place to experiment with whole-system optimization techniques<br />
<br />
It was written by Darren Hart.<br />
<br />
=== Basic use ===<br />
To use the poky-tiny distro, adjust the DISTRO setting in your conf/local.conf file.<br />
That is, set it to: "DISTRO=poky-tiny"<br />
<br />
poky-tiny does not include a target-side package manager, so it is useful, to avoid<br />
extra dependencies, to use it with the IPKG package management scheme. This is the lightest-weight<br />
package management scheme. Set this in your conf/local.conf file:<br />
PACKAGE_CLASSES ?= "package_ipk"<br />
<br />
Then do a basic build of the system:<br />
$ bitbake core-image-minimal<br />
<br />
Resulting images should appear in your <build-dir>/tmp/deploy/images directory.<br />
<br />
== FAQ ==<br />
* where is poky-tiny defined?<br />
** poky-tiny is defined in <yocto-dir>/meta-yocto/conf/distro/poky-tiny.conf. Some other recipes and images have been modified to support the features in poky-tiny.<br />
** The kernel recipe for poky-tiny is in <yocto-dir>/meta/recipes-kernel/linux/linux-yocto-tiny_x.x.bb<br />
* What images are supported?<br />
** As of poky-danny-8.0 (the 1.3 release of yocto), poky-tiny.conf defined the following images: IMAGE_FSTYPES = "ext2 cpio.gz" This means it will build both an ext2 filesystem image, and a cpio.gz image (suitable for use as an initramfs).<br />
* What machines are supported (are there any restrictions)?<br />
** in the kernel recipe file, it has COMPATIBLE_MACHINE="(qemux86)"<br />
* What features have been eliminated?<br />
* What is the size difference between poky-tiny and poky (core-image-minimal)?<br />
* Are there differences in the way poky-tiny is customized, from the way default 'poky' is customized? (eg. gotchas for adding to IMAGE_INSTALL or IMAGE_FEATURES)?<br />
<br />
== Creating your own tiny-based distro ==<br />
You can create your own distro, based on the tiny work, by copying the poky-tiny.conf file<br />
to your own layer, and editing it from there.<br />
<br />
Assuming you are calling your layer 'meta-foo', you could do the following:<br />
<br />
* create your meta-foo layer (see other docs for this)<br />
* copy the poky-tiny distro configuration file to your own layer<br />
$ install -p meta-foo/conf/distro<br />
$ cp meta-yocto/conf/distro/poky-tiny.conf meta-foo/conf/distro/foo-tiny.conf<br />
* edit your conf/local.conf to use your foo-tiny.conf distro<br />
$ vi <build-dir>/conf/local.conf<br />
[change it so "DISTRO?=foo-tiny"]<br />
<br />
== Adjusting poky-tiny ==<br />
=== Controlling LIBC features ===<br />
Inside foo-tiny.conf (derived from poky-tiny.conf), you can specify what LIBC features to support<br />
by modifying the DISTRO_FEATURES_LIBC variable.<br />
<br />
This variable is declared to be a space-separated list of other DISTRO_FEATURES_LIBC_xxx variables.<br />
To turn on or off features in libc, edit the values of these variables.<br />
<br />
==== eglibc ====<br />
To see different options that are available, see the file:<br />
<yocto-dir>/meta/recipes-core/eglibc/eglibc-options.inc<br />
<br />
Listed in that file are the routines: distro_features_check_deps() and features_to_eglibc_settings(),<br />
which map items listed in DISTRO_FEATURES_LIBC into specific eglibc settings.<br />
<br />
==== uclibc ====<br />
To see different options that are available, see the file:<br />
<yocto-dir>/meta/recipes-core/uclibc/uclibc-config.inc<br />
<br />
Listed in that file is the routine: features_to_uclibc_settings(),<br />
which maps items listed in DISTRO_FEATURES_LIBC into specific uclibc settings.<br />
<br />
=== Controlling kernel features ===<br />
<br />
=== Controlling busybox features ===<br />
To adjust busybox features, it's necessary to have your own defconfig and the busybox recipe must be appended to tell bitbake where it can find this defconfig. In its most basic form it could look like this: <br />
<nowiki><br />
$ cd /path/to/poky/directory<br />
$ tree recipes-core/<br />
recipes-core/<br />
├── busybox_1.20.2<br />
│ └── defconfig<br />
└── busybox_1.20.2.bbappend<br />
<br />
1 directory, 2 files<br />
</nowiki><br />
<br />
== Troubleshooting the build ==<br />
<br />
== Invoking qemu with poky-tiny images ==<br />
Runqemu doesn't understand poky-tiny (or initramfs?). Try executing qemu directly instead. Here's the template:<br />
<br />
$ qemu-system-i386 -kernel path/to/kernel -initrd path/to/image.cpio.gz -nographic -append "console=ttyS0 root=/dev/ram0"<br />
<br />
Here the actual full command I used:<br />
<br />
$ tmp/sysroots/x86_64-linux/usr/bin/qemu-system-i386 -kernel tmp/deploy/images/bzImage-qemux86.bin -initrd tmp/deploy/images/core-image-minimal-qemux86.cpio.gz -nographic -append "console=ttyS0 root=/dev/ram0"<br />
<br />
=== Some information about the running system ===<br />
You can poke around, and see the status of various things. 'ps' shows only 22 processes running, with only 3 user-space (ie not kernel threads):<br />
<br />
# ps | grep -v [[]<br />
PID USER VSZ STAT COMMAND<br />
1 root 2004 S {init} /bin/sh /init<br />
38 root 2144 S sh<br />
41 root 2144 R ps<br />
<br />
So... busybox is really the only executable on the system, and it is providing /bin/sh. /init is a shell script,<br />
which will run /etc/rc.local, if one is present. There's a sample in /etc/rc.local.sample that you can use as a<br />
starting point to customize the init process. If you turn on packages in yocto, there will be init scripts deposited<br />
in /etc/init.d, which you can call from either /init or /etc/rc.local to invoke (none of that fancy sysV rc init scripts here!)<br />
<br />
I booted with mem=24M (that was about as small as I could go) and saw the following memory utilization:<br />
# free<br />
total used free shared buffers<br />
Mem: 19724 5944 13780 0 0<br />
-/+ buffers: 5944 13780<br />
Swap: 0 0 0<br />
<br />
The filesystem is a little over 3M in size:<br />
# du -sh /<br />
3.2M /<br />
<br />
Here's a sample of what the filesystem looks like (as of yocto-danny-8.0), with results sorted by size<br />
and /sys, /proc and /dev omitted:<br />
# find / -type f -xdev | xargs ls -laSr<br />
-rw-r--r-- 1 root root 0 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.dep<br />
-rw-r--r-- 1 root root 0 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.builtin.bin<br />
-rw-r--r-- 1 root root 0 Nov 14 00:45 /etc/network/nm-disabled-eth0<br />
-rw-r--r-- 1 root root 0 Nov 14 00:45 /etc/motd<br />
-rw-r--r-- 1 root root 0 Nov 14 00:14 /etc/ld.so.conf<br />
-rw-r--r-- 1 root root 0 Nov 14 00:45 /etc/default/usbd<br />
-rw-r--r-- 1 root root 6 Nov 14 22:05 /var/volatile/run/ifstate<br />
-rw-r--r-- 1 root root 8 Nov 14 00:45 /etc/hostname<br />
-rw-r--r-- 1 root root 12 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.symbols.bin<br />
-rw-r--r-- 1 root root 12 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.dep.bin<br />
-rw-r--r-- 1 root root 12 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.alias.bin<br />
-rw-r--r-- 1 root root 13 Nov 14 21:24 /etc/version<br />
-rw-r--r-- 1 root root 13 Nov 14 21:24 /etc/timestamp<br />
-rw-r--r-- 1 root root 26 Nov 14 00:45 /etc/host.conf<br />
-rw-r--r-- 1 root root 38 Nov 14 00:45 /etc/filesystems<br />
-rw-r--r-- 1 root root 44 Nov 14 00:45 /etc/hosts<br />
-rw-r--r-- 1 root root 45 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.alias<br />
-rwxr-xr-x 1 root root 49 Nov 14 00:22 /usr/share/udhcpc/default.script<br />
-rw-r--r-- 1 root root 49 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.symbols<br />
-rw-r--r-- 1 root root 52 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.devname<br />
-rw-r--r-- 1 root root 72 Nov 14 00:45 /etc/issue.net<br />
-rw-r--r-- 1 root root 74 Nov 14 00:45 /etc/issue<br />
-rwxr-xr-x 1 root root 93 Nov 13 20:19 /etc/default/devpts<br />
-rw-r--r-- 1 root root 109 Nov 14 00:45 /etc/shells<br />
-rw-r--r-- 1 root root 131 Nov 14 21:24 /lib/modules/3.4.11-yocto-tiny/modules.softdep<br />
-rw-r--r-- 1 root root 132 Nov 14 00:45 /etc/network/interfaces<br />
-rwxr-xr-x 1 root root 152 Nov 14 00:45 /etc/skel/.profile<br />
-rwxr-xr-x 1 root root 270 Nov 13 20:19 /etc/init.d/hostname.sh<br />
-rwxr-xr-x 1 root root 289 Nov 13 20:19 /etc/init.d/reboot<br />
-rwxr-xr-x 1 root root 321 Nov 13 20:19 /etc/init.d/save-rtc.sh<br />
-rwxr-xr-x 1 root root 410 Nov 14 00:45 /etc/skel/.bashrc<br />
-rwxr-xr-x 1 root root 438 Nov 13 20:19 /etc/init.d/sendsigs<br />
-rw-r--r-- 1 root root 446 Nov 14 21:23 /etc/group<br />
-rw-r--r-- 1 root root 465 Nov 14 00:45 /etc/nsswitch.conf<br />
-rwxr-xr-x 1 root root 473 Nov 14 21:24 /init<br />
-rwxr-xr-x 1 root root 492 Nov 13 20:19 /etc/init.d/banner.sh<br />
-rwxr-xr-x 1 root root 510 Nov 13 20:19 /etc/init.d/halt<br />
-rwxr-xr-x 1 root root 516 Nov 13 20:19 /etc/init.d/umountfs<br />
-rwxr-xr-x 1 root root 526 Nov 13 20:19 /etc/init.d/devpts.sh<br />
-rwxr-xr-x 1 root root 578 Nov 13 20:19 /etc/init.d/single<br />
-rwxr-xr-x 1 root root 585 Nov 13 20:19 /etc/init.d/rmnologin.sh<br />
-rw-r--r-- 1 root root 586 Nov 14 00:20 /usr/share/run-postinsts/run-postinsts.awk<br />
-rwxr-xr-x 1 root root 609 Nov 14 00:20 /etc/init.d/run-postinsts<br />
-rwxr-xr-x 1 root root 632 Nov 14 00:45 /etc/rc.local.sample<br />
-rw-r--r-- 1 root root 651 Nov 14 00:22 /etc/syslog-startup.conf.busybox<br />
-rwxr-xr-x 1 root root 660 Nov 13 20:19 /etc/init.d/sysfs.sh<br />
-rw-r--r-- 1 root root 704 Nov 14 00:45 /etc/fstab<br />
-rwxr-xr-x 1 root root 711 Nov 13 20:19 /etc/init.d/umountnfs.sh<br />
-rw-r--r-- 1 root root 719 Nov 14 21:23 /etc/passwd<br />
-rw------- 1 root root 737 Nov 14 22:22 /.ash_history<br />
-rw-r--r-- 1 root root 783 Nov 14 21:24 /etc/ld.so.cache<br />
-rwxr-xr-x 1 root root 809 Nov 14 00:45 /etc/network/if-pre-up.d/nfsroot<br />
-rw------- 1 root root 836 Nov 14 21:24 /var/volatile/cache/ldconfig/aux-cache<br />
-rw-r--r-- 1 root root 847 Nov 14 00:45 /etc/profile<br />
-rwxr-xr-x 1 root root 859 Nov 13 20:19 /etc/init.d/mountall.sh<br />
-rwxr-xr-x 1 root root 878 Nov 14 00:45 /etc/init.d/modutils.sh<br />
-rw-r--r-- 1 root root 887 Nov 14 00:45 /etc/rpc<br />
-rw-r--r-- 1 root root 1123 Nov 13 20:19 /etc/init.d/functions.initscripts<br />
-rwxr-xr-x 1 root root 1349 Nov 13 20:19 /etc/init.d/urandom<br />
-rwxr-xr-x 1 root root 1540 Nov 13 20:19 /etc/init.d/mountnfs.sh<br />
-rw-r--r-- 1 root root 1633 Nov 14 00:45 /etc/inputrc<br />
-rwxr-xr-x 1 root root 1711 Nov 14 00:22 /etc/init.d/syslog.busybox<br />
-rw-r--r-- 1 root root 1740 Nov 13 20:19 /etc/default/volatiles/00_core<br />
-rwxr-xr-x 1 root root 1752 Nov 13 20:19 /etc/init.d/bootmisc.sh<br />
-rwxr-xr-x 1 root root 1909 Nov 14 00:45 /etc/init.d/networking<br />
-rw-r--r-- 1 root root 2146 Nov 14 00:22 /etc/busybox.links<br />
-rwxr-xr-x 1 root root 2514 Nov 14 00:22 /etc/init.d/hwclock.sh<br />
-rwxr-xr-x 1 root root 2548 Nov 14 00:22 /etc/udhcpc.d/50default<br />
-rw-r--r-- 1 root root 2933 Nov 14 00:45 /etc/protocols<br />
-rwxr-xr-x 1 root root 3229 Nov 13 20:19 /etc/init.d/checkroot.sh<br />
-rwxr-xr-x 1 root root 4409 Nov 13 20:16 /usr/sbin/update-rc.d<br />
-rwxr-xr-x 1 root root 4524 Nov 14 00:45 /usr/bin/update-alternatives<br />
-rwxr-xr-x 1 root root 5249 Nov 13 20:19 /etc/init.d/populate-volatile.sh<br />
-rwxr-xr-x 1 root root 6666 Nov 13 20:19 /etc/device_table<br />
-rwsr-xr-x 1 root root 9544 Nov 14 00:14 /usr/lib/eglibc/pt_chown<br />
-rwxr-xr-x 1 root root 9740 Nov 14 00:14 /lib/libutil-2.16.so<br />
-rwxr-xr-x 1 root root 13828 Nov 14 00:14 /lib/libdl-2.16.so<br />
-rw-r--r-- 1 root root 19398 Nov 14 00:45 /etc/services<br />
-rwxr-xr-x 1 root root 22020 Nov 14 00:14 /lib/libnss_dns-2.16.so<br />
-rwxr-xr-x 1 root root 26064 Nov 14 00:14 /lib/libcrypt-2.16.so<br />
-rwxr-xr-x 1 root root 30624 Nov 14 00:14 /lib/librt-2.16.so<br />
-rwxr-xr-x 1 root root 34588 Nov 14 00:14 /lib/libnss_compat-2.16.so<br />
-rwxr-xr-x 1 root root 46980 Nov 14 00:14 /lib/libnss_files-2.16.so<br />
-rwxr-xr-x 1 root root 83716 Nov 14 00:14 /lib/libresolv-2.16.so<br />
-rwxr-xr-x 1 root root 87860 Nov 14 00:14 /lib/libnsl-2.16.so<br />
-rwxr-xr-x 1 root root 96128 Nov 14 00:14 /lib/libpthread-2.16.so<br />
-rwxr-xr-x 1 root root 127228 Nov 14 00:14 /lib/ld-2.16.so<br />
-rwxr-xr-x 1 root root 251328 Nov 14 00:14 /lib/libm-2.16.so<br />
-rwxr-xr-x 1 root root 524924 Nov 14 00:14 /sbin/ldconfig<br />
-rwsr-xr-x 1 root root 554820 Nov 14 00:22 /bin/busybox<br />
-rwxr-xr-x 1 root root 1056128 Nov 14 00:14 /lib/libc-2.16.so<br />
<br />
busybox, ldconfig and libc (and other libc-related libs) make up about 95% of the system.<br />
<br />
If busybox were statically linked, and ldconfig and libc were omitted, I believe it would<br />
reduce the size of the system substantially.<br />
<br />
=== exiting the system ===<br />
There is no 'shutdown' command, but you can use 'ctrl-a to execute a command to the qemu monitor, and 'ctrl-a b' to issue a sysrq to the Linux kernel.<br />
You can do a sysrq-B to do a reboot. Do: ctrl-a h to see available commands, and ctrl-a x to exit qemu.<br />
<br />
== Resources ==<br />
* Presentation: [http://elinux.org/images/2/2b/Elce11_hart.pdf Tuning Linux For Embedded Systems: When Less Is More] by Darren Hart, ELC Europe 2011, October 2011, Prague, Czech Republic</div>Dennis Meier