https://wiki.yoctoproject.org/wiki/api.php?action=feedcontributions&user=WikiSysop&feedformat=atomYocto Project - User contributions [en]2024-03-29T15:30:23ZUser contributionsMediaWiki 1.39.5https://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.1_Schedule&diff=1375Yocto 1.1 Schedule2011-04-19T17:10:08Z<p>WikiSysop: Protected "Yocto 1.1 Schedule" ([edit=sysop] (indefinite) [move=sysop] (indefinite))</p>
<hr />
<div>= Yocto Project 1.1 (release date: October 6, 2011) =<br />
----<br />
The detailed milestone map for the 1.1 release of Yocto Project is as below.<br />
<br />
== pre-M1 (March 14 to April 18 -- Feature List and Schedule Defined April 18) ==<br />
* Features Submitted to web - by April 1st<br />
* Features prioritized and added to schedule - by April 12th<br />
<br />
== M1 (Apr 18 to Jun 13 -- Design Complete Apr 25, Dev Complete May 23, Stabilize Complete Jun 6, Release Complete Jun 13) ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Architecture || OE Core || Restructuring, renaming, rebranding || 1 || Review || Richard || Architect ||<br />
|-<br />
|| 1.0 Carryover || image creator (I)|| finish the Image Creator to add features pushed out from 1.0 || 1 || Accept || Joshua + Jessica || 1.0 Carryover ||<br />
|-<br />
|| 1.0 Carryover || multi-lib || multi-lib support for 32-bit & 64-bit and capable of being installed at the same time || 1 || Review || Richard (Qing) || 1.0 Carryover ||<br />
|-<br />
|| Meta-Data || OE Comparison || Compare Yocto core set against integration work in OE and other distributions looking for bug fixes, (relevant) feature enhancements, and integration/policy hints. || 1 || Accept || Mark || Meta-data ||<br />
|-<br />
|| BSPs || Support for AVX as in kernel 2.6.30. - Already in 1.0? || Any toolchain support needed? Is it already in GCC? Ensure part of toolchain update (if not already present). Verify with Bruce that AVX is enabled in kernel version XXX?<br />
|| 1 || Accept || Saul / Nitin || Jay / ECG ||<br />
|-<br />
|| Misc || User creation at pre-install || || 1 || Accept || Mark (ScottG) || Architect ||<br />
|-<br />
|| Build || Autobuilder maintenance || Bring scripts into configuration or get git repo working for those that can't be brought in. (~1.5 weeks)|| 1 || Accept || Beth || Beth ||<br />
|-<br />
|| Build || License tracking || Get common licenses for all packages. (takes ~3 days) || 1 || Accept || Beth || Beth ||<br />
|-<br />
|| Overall || Process Improvement || Host a retrospective to discuss what went well and what can be improved in Yocto 1.0. || 1 || Accept || Beth || Beth ||<br />
|-<br />
|| Project || Release Readiness || Release Readiness Meeting || 1 || Jun-6 || Julie || Julie||<br />
|-<br />
|| Point Release || Build/Release/QA || We need a point release to fix bugs targeted for point release. (Beths end: ~1-2 days of work with PRC. Release is trivial.)|| 1 || Accept || Beth/Yongkang|| Team||<br />
|-<br />
|| Performance || Plan for Performance || This is a placeholder to spend time this milestone determining the plan for improving performance. Various P1, P2, P3 tasks will be output as a result of this planning. || 1 || Review || Richard/Dongxiao || Team||<br />
|-<br />
|| Documentation || OOB documentation || Create an out of box guide for giveaway systems built using Yocto by EO May. || 1|| Review || ScottR || Julie || <br />
|-<br />
|| kernel || kernel tools || refactor/clean the kernel tools for more general use. include the tools withing the kernel repo, not in a separate repo|| 1|| Review || Bruce || Bruce ||<br />
|-<br />
|| kernel || kernel build || auto yoctization. allow the building of arbitrary repos and kernel versions via the yocto kernel meta data|| 1|| Review || Bruce || Bruce ||<br />
|-<br />
|| kernel || kernel update ||kernel dev/next repo created. feature merges (fs, boot, tiny, controllers, etc). reference tree merges (omap, davinci, etc)|| 1|| Review || Bruce || Bruce ||<br />
|-<br />
|| ADT || Eclipse-native tools interface ||More integrated with upstream once there's integrated Linux tools that meets our need, e.g. lttng-remote || 2|| Review || Jessica || ADT Team ||<br />
|-<br />
|| ?? || End of package revision ||replace with a network service || 2|| Review || Jessica || RP Notes||<br />
|-<br />
|| QA || Overall Test Plan || Create an overall Test Plan with details on Strategy, Approach, Types of Testing, Features included and not included, Hardware needed, Schedule, and Resources and publish to Wiki || 1|| Accept - May 6|| Jiajun|| Jiajun||<br />
|-<br />
|| QA || Test Execution Plan || Create a Test Execution Plan with specific Test Cases || 1|| Accept - May 16 || Jiajun|| Jiajun||<br />
|}<br />
<br />
== M2 (May 30 to Jul 25 -- Design Complete Jun 6, Dev Complete Jul 4, Stabilize Complete Jul 18, Release Complete Jul 25) ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| 1.0 Carryover || Image Creator (II) || finish the Image Creator to add polish and community requested features || 1 || Accept || Joshua + Jessica || 1.0 Carryover ||<br />
|-<br />
|| Architecture || Layer Tooling || This includes the architectural work plus implementing the changes || 1 || Review || Richard || Architect ||<br />
|-<br />
|| Meta-data || Upstream our patches || Placeholder for time for the team to upstream patches || 1 || Accept || Saul || Meta-Data Team||<br />
|-<br />
|| Meta-data|| Error handling in bitbake || add additional error handling to bitbake (check bugzilla for existing error handling and warning bugs) || 1 || Accept || Saul (ScottG) || Architect ||<br />
|-<br />
|| ADT || Changes for Image Creator || Eclipse changes pending Image Creator || 1 || Review || Jessica || ADT Team||<br />
|-<br />
|| ADT || Secure login || Eclipse changes pending Image Creator || 2 || Review || Jessica || ADT Team||This need to work with CDT & TCF community, so may beyond our 1.1 release cycle, but the work will get started in M2 - MX<br />
|-<br />
|| BSP || Tutorials || Create tutorials and documentation on how to create a BSP || 1 || Accept || Tom, Scott || Team||<br />
|-<br />
|| Kernel|| Fast Boot Time || 2 second boot time target || 1 || Accept || Darren|| Team ||<br />
|-<br />
|| Build || Meta-Targets || Part of the challenge of autobuilder is that you have to go into autobuilder, edit script, reconfigure, to change just one build target. This is error prone. What we need is a meta-target where Beth can say she wants to build Poky-image-sato for QEMU x86 and have it just do that. Beth thinks this is done via an override to the web page. (takes ~2 weeks) || 1 || Accept || Beth || Beth||<br />
|-<br />
|| Build || License tracking || Build a parser to do license tracking more gracefully and make sure all recipes are correct. (takes ~2 weeks) || 1 || Accept || Beth || Beth||<br />
|-<br />
|| Build || Autobuilder Infrastructure || Bring up additional autobuilders and work with sysadmin to configure. (2 days per machine for OS. 1 hour for ab setup)|| 1 || Accept || Beth || Beth||<br />
|-<br />
|| Misc || adding eglibc config control || this goes with the package config options || 1.5 || Accept || Mark || Architect ||<br />
|-<br />
|| Misc || Directory Ownership || || 1.5 || Accept || Mark (Qing) || Architect || a bit concerned this will take longer then expected<br />
|-<br />
|| Project || Release Readiness || Release Readiness Meeting || 1 || Jul-18 || Julie || Julie||<br />
|-<br />
|| BSPs || BSP update/intro ||determine and integrate / create arch reference BSPs (e500, Cortex, ARM, MIPs)|| 2|| Review || Bruce/Richard/team || Bruce ||<br />
|-<br />
|| kernel || BSP config cleanup||BSP config cleanup/refactoring. Update to new kernel rev. Investigate Kconfig alignment|| 1|| Review || Bruce|| Bruce ||<br />
|-<br />
|| kernel || inter-core comms||investigate/report/merge intercore communication methods (mcapi, dsplink,etc). extend as appropriate|| 2|| Review || Bruce|| Bruce ||<br />
|-<br />
|| QA || Test Execution Plan || Create a Test Execution Plan with specific Test Cases || 1|| Accept - June 27 || Jiajun|| Jiajun||<br />
<br />
|}<br />
<br />
== M3 (Jul 11 to Aug 15 -- Design Complete Jul 18, Dev Complete Jul 25, Stabilize Complete Aug 8, Release Complete Aug 15) ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Build || Release Scripts || Create Release Scripts for OCT 2011 release (one week)|| 1 || Review || Beth || Beth || <br />
|-<br />
|| Project || Release Readiness || Release Readiness Meeting || 1 || Aug-8 || Julie || Julie||<br />
|-<br />
|| Alpha || Alpha Program || Participants determined - Aug 1; Program - Aug 8-22; Feedback available - Aug 25 || 1 ||Accept || Julie || Julie||<br />
|-<br />
|| kernel || usecases|| BSP config streamlining, building the kernel standalone, yoctoization, meta data sharing || 1 ||Review || Bruce|| Bruce||<br />
|-<br />
|| ADT || Eclipse plug-in upgrate to Indigo|| Update yocto plug-in to Eclipse 3.7 (Indigo) || 1 || Review || Jessica || ADT Team||<br />
|-<br />
|| ADT || Eclipse plug-in Systemtap support|| Make it easy and convenient for the user to write and execute Systemtap scripts from the IDE. || 2 ||Review || Jessica || Tom||<br />
|-<br />
|| ADT || Eclipse plug-in "perf scription" support|| Make it easy and convenient for the user to write and execute 'perf scripts' from the IDE. || 2 ||Review || Jessica || Tom||<br />
|-<br />
|| ADT || Enhance the deploy in remote debug || Make it easy and convenient for the user to write and execute 'perf scripts' from the IDE. || 2 ||Review || Jessica || Lianhao ||<br />
|-<br />
|| ADT || More test cases about toolchain in autobuilder || Add the test projects that ADT team has been using for testing toolchain into autobuilder automated testing || 2 ||Review || Jessica || Liping ||<br />
|-<br />
|| QA || Test Execution Plan || Create a Test Execution Plan with specific Test Cases || 1|| Accept - Jul 18 || Jiajun|| Jiajun||<br />
|}<br />
<br />
== M4 (Aug 15 to Oct 6 -- Stabilize Complete Aug 29, Release Complete Oct 3) ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Project || Release Candidate 1 || RC1 generated || 1 || Aug-29|| Beth || Team || <br />
|-<br />
|| Project || Release Candidate 2 || RC2 generated || 1 || Sep-5|| Beth || Team || <br />
|-<br />
|| Project || Release Candidate 3 || RC3 generated || 1 || Sep-12|| Beth || Team || <br />
|-<br />
|| Project || Release Candidate 4 || RC4 generated || 1 || Sep-19|| Beth || Team || <br />
|-<br />
|| Project || Release Readiness || Release Readiness Meeting || 1 || Sep-26 || Julie || Julie||<br />
|-<br />
|| QA || Holiday || QA team on holiday Oct 1 - 7 || 1 || Oct 1-7 || QA || QA ||<br />
|}</div>WikiSysophttps://wiki.yoctoproject.org/wiki/index.php?title=FAQ&diff=243FAQ2010-10-27T06:38:09Z<p>WikiSysop: Created page with ''''Yocto Project Public Messages and FAQ''' Final 10/26/2010 '''Q: What is the Yocto Project?''' '''A:''' The Yocto Project provides open source, high-quality infrastructure…'</p>
<hr />
<div>'''Yocto Project Public Messages and FAQ'''<br />
<br />
Final 10/26/2010<br />
<br />
<br />
<br />
'''Q: What is the Yocto Project?'''<br />
<br />
'''A:''' 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 Linux Foundation welcomes the participation of embedded vendors, developers, and other open source projects.<br />
<br />
<br />
<br />
'''Q: What does the Linux Foundation hope to achieve with the Yocto Project?'''<br />
<br />
'''A:''' 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 />
'''Q: How will the Yocto Project help Linux reach a wider embedded audience?'''<br />
<br />
'''A:''' This collaboratively developed, open source build system focused on the embedded segment will speed embedded vendors’ time to market by establishing a shared build infrastructure. This will enable 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 />
'''Q: Isn’t the Yocto Project just yet another Linux distribution?'''<br />
<br />
'''A:''' No. The Yocto Project is a build system and tools that enables developers to construct their own custom distributions, targeted for specific embedded devices. It is not, itself, a complete Linux distribution. Rather, it is capable of outputting 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 />
'''Q: What benefits does the Yocto Project provide embedded developers and how is the Yocto Project superior to existing, similar tools?'''<br />
<br />
'''A:''' Unlike build systems based on shell scripts or makefiles, the Yocto Project automates the fetching of sources 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; it supports both major Linux packaging systems (.rpm and .deb), as well as the embedded-friendly ipkg 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 inherits the core build tool (bitbake) and metadata syntax from OpenEmbedded, which is currently the most popular embedded development tool. This commonality will provide automatic familiarity for developers already using OpenEmbedded. However, the learning curve for getting started with the Yocto Project and Poky is shallower. It is easier for new users to create a working distribution with the Yocto Project. <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 and Anjuta IDEs, or it may 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 />
'''Q: How does the existing embedded workflow compare to the Yocto Project and where can embedded developers save time?'''<br />
<br />
'''A:''' 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 OSV who offers products and services compatible with the Yocto Project.<br />
<br />
<br />
<br />
'''Q: Will the Yocto Project have a special governance model, or will it be managed as an open source project?'''<br />
<br />
'''A:''' The Yocto Project will be governed as an open source project working group under the auspices of the Linux Foundation. There will be a Steering Group consisting of representatives from the major sponsoring organizations. This group will make decisions by majority vote, but the vast majority of decisions will be delegated to Maintainers; the Maintainers will only use the Steering Group to break deadlocks or to make final decisions about roadmaps. In addition, there will be Interest Groups who drive project feature requirements and an architect who will coordinate the work of the Maintainers and set project direction under the guidance of the Steering Group.<br />
<br />
<br />
<br />
'''Q: Why not just call this project Poky? What has changed between Poky and the Yocto Project?'''<br />
<br />
'''A:''' The Yocto Project is an umbrella project, similar to freedesktop.org. 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 indeed the largest part of the Yocto Project, and Poky will continue 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 />
<br />
<br />
'''Q: Who defines the root filesystem and metadata?'''<br />
<br />
'''A:''' 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 />
'''Q: What are the criteria for baseline metadata?'''<br />
<br />
'''A:''' 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 />
'''Q: What tool sets are included in the Yocto Project? When will they be available?'''<br />
<br />
'''A:''' The development tool chain is based on GCC. However, if a project contributor wished to add metadata that uses another tool chain, the project would be happy to consider it.<br />
<br />
<br />
<br />
'''Q: What about graphics drivers? Will they be validated and integrated?'''<br />
<br />
'''A:''' Yes.<br />
<br />
<br />
<br />
'''Q: How will graphics IP in GPL drivers be handled?'''<br />
<br />
'''A:''' The BSPs supplied in the open source project will generally be focused on open source code.<br />
<br />
<br />
<br />
'''Q: Where do BSPs come from? Who creates them? What if they need to include proprietary information?'''<br />
<br />
'''A:''' A small set of example BSPs will be created and 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 will be handled by the supplier.<br />
<br />
<br />
<br />
'''Q: Are there tools that allow the removal of a package from the build?'''<br />
<br />
'''A:''' Yes. The recipe for a given distribution can be modified to remove a package. An end developer may remove a package from the specified path in the build process. This allows for a completely customized Linux distribution.<br />
<br />
<br />
<br />
'''Q: How can one view the dependencies of packages and the resulting growth in code size as packages are added?'''<br />
<br />
'''A:''' There are tools within Bitbake which allow this.<br />
<br />
“bitbake -g targetname” will create depends.dot and task-depends.dot files in the current directory. They show which packages and tasks depend on which other packages and tasks and are useful for debugging purposes. "bitbake -g -u depexp targetname" will show 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 />
<br />
<br />
'''Q: What is the path for upgrading just drivers, or for upgrading drivers and related updates to the kernel?'''<br />
<br />
'''A:''' For a given 6-month release of the Yocto Project, the version of the kernel will be frozen 6 weeks before release. <br />
<br />
<br />
<br />
'''Q: How often is the kernel updated? How will we know what version of the kernel will be used in any particular Yocto Project release?'''<br />
<br />
'''A:''' Given the release cycle for the kernel, every 6-month release of the Yocto Project will usually have a new kernel. Specific announcements will be made on the Yocto Project mailing list and blogs.<br />
<br />
<br />
<br />
'''Q: Is the kernel included in the Yocto Project?'''<br />
<br />
'''A:''' 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 />
'''Q: What are some possible debugging targets?'''<br />
<br />
'''A:''' QEMU is the target for emulation. Several actual hardware targets will also be supported, as well as software emulators for various hardware models as provided by silicon vendors.<br />
<br />
<br />
<br />
'''Q: What is the overall support plan for the Yocto Project?'''<br />
<br />
'''A:''' Security patches and critical bug fixes will be supplied one release back. No tool chain or kernel changes will be allowed for these updates. Support for longer periods of time can be supplied by commercial OSVs.<br />
<br />
<br />
<br />
'''Q: What is meant by automated test capability?'''<br />
<br />
'''A:''' The Yocto Project will include a standard framework for testing on target devices. This will allow many existing tests to be reused across projects, reducing rework.<br />
<br />
<br />
<br />
'''Q: If a customer wants a commercial distribution of the Yocto Project, are there potential candidates for productization and commercial distribution?'''<br />
<br />
'''A:''' Yes, the Yocto Project is currently in discussion with several commercial OSVs. <br />
<br />
<br />
<br />
'''Q: For which software development boards will Yocto Project v0.9 be validated?'''<br />
<br />
'''A:''' ARM Beagleboard, Intel Atom Black Sand, PowerPC - fsl-mpc8315e-rdb, and MIPS - Ubiquity Networks Router Station Pro<br />
<br />
<br />
<br />
'''Q: Is user interface development possible with the Yocto Project?'''<br />
<br />
'''A:''' 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 like QT, Clutter, or GTK+, all of which are included.<br />
<br />
<br />
<br />
'''Q: Will the Yocto Project be a project or a product? How much customer effort is required to productize the Yocto Project?'''<br />
<br />
'''A:''' 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 />
<br />
<br />
'''Q: Who may I contact for further questions regarding the Yocto Project?'''<br />
<br />
'''A:''' For any additional questions, please contact Jennifer Cloer of the Linux Foundation at jennifer@linuxfoundation.org.</div>WikiSysophttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Architecture&diff=150Yocto Architecture2010-10-25T09:04:20Z<p>WikiSysop: Created page with '= Yocto Project Architecture Whitepaper = == Embedded Market == The embedded market is characterised by its wide range of devices which operate in many different environments …'</p>
<hr />
<div>= Yocto Project Architecture Whitepaper =<br />
<br />
== Embedded Market ==<br />
<br />
The embedded market is characterised by its wide range of devices which <br />
operate in many different environments e.g. home users, industrial devices, <br />
medical use or data centres. These devices are tailored to their environments <br />
and vastly differ in connectivity capabilities, input and output methods and <br />
features like processing power, memory capacity and available data storage. <br />
These systems need software to function and Linux is desirable due to its <br />
adaptability, its functionality, quality and no royalties model.<br />
<br />
The market is highly fragmented with many different approaches to software <br />
being adopted using both open source and proprietary solutions. Each market <br />
sub-segment tends to have a preferred approach but there are no accepted <br />
standards.<br />
<br />
Anyone working in this market faced some difficult issues trying to deal with this <br />
fragmentation. One approach would be to take each sub-segment in turn and try <br />
and create solutions targeting that segment. This would be costly in resources. <br />
An alternative is that offered by Yocto Linux - to create a common best practises <br />
infrastructure which can fulfill the software needs of most embedded market segments.<br />
<br />
Building a common base set of tools and a reference embedded Linux stack means this <br />
non-differentiation work which everyone currently does themselves can be shared in <br />
the form of a common project. Organisations can then focus where their effort is best <br />
spent, on their differentiation and project features.<br />
<br />
== Yocto Project ==<br />
<br />
The objective is to look at all the solutions currently in the embedded space <br />
and then take the best of what is available, fill in any missing functionality <br />
and create something which can lead the market. <br />
<br />
By doing this, the project users share the cost of the base stack and there is<br />
a common standard set of tools used by the marketplace rather than everyone having <br />
to do this themselves.<br />
<br />
== Existing Build System Solutions ==<br />
<br />
Some kind of build system is the cornerstone of most embedded projects and <br />
the Yocto Project is no different. There are many such solutions in the embedded space. In <br />
order to capture the attention of the industry this project requires something <br />
open that people can see and use without royalties, much like Linux itself. <br />
For this reason only open source systems are contenders for this project. <br />
<br />
There are a variety of possible existing contenders and its worth evaluating <br />
these for their strengths and weaknesses:<br />
<br />
Buildroot - One of the older embedded build systems, this is makefile driven <br />
and is a natural evolution of the scripts based build solutions many people <br />
start with when starting an embedded project. The general feeling of this <br />
system is that it has had its day, it was a good learning experience but <br />
lacked the fundamental structure to its processes to grow into anything bigger <br />
than what it is. It lacks fundamental features such as packaging.<br />
<br />
E2-Factory - A more modern from scratch solution that it very structured and <br />
rigorous in its build processes. Sadly whilst the core tool is open source, no <br />
metadata is available so its ruled out. It does have some neat features like <br />
dependency checksumming which can be learnt from though. <br />
<br />
Desktop (PC) Distribution Systems - Whilst not embedded solutions, these are <br />
widely used for PCs so should be considered. The fundamental problem is that <br />
these systems all promote a "one size fits all" approach to software and do <br />
not support customisation for multiple targets easily or well. You cannot <br />
build two distributions of different character from one set of metadata with <br />
these solutions. In the embedded space this rules the solution out but again, <br />
there are things that can be learnt from like the OBS web interfaces.<br />
<br />
PTXdist - Makefile driven, more advanced than buildroot but is small and only <br />
caters for a small segment of the market.<br />
<br />
LTIB - This is a system developed and pushed by Freescale which combines spec <br />
files with a kconfig menu front end. Its nice to have the menu control of the <br />
system but it has limited package support, limited platform support and is <br />
very tied to the rpm format and is not as structured, mature or comprehensive <br />
as other solutions in the marketplace.<br />
<br />
OpenEmbedded - If there were an industry standard, this would be it. It was <br />
written to learn from all the mistakes in buildroot, has a well defined <br />
structure to its metadata and has by far the largest coverage of open source <br />
software. It dropped Makefiles in favour of a custom data file format of its <br />
own with tools to handle them (bitbake). Feature wise its also the most <br />
advanced system in the market and it was specifically designed for the <br />
customisation needs of the embedded market space. It does lack some features<br />
such as checksumming but the structure would allow them to be added.<br />
<br />
Poky - Created by Openedhand as a commercial version of OpenEmbedded and the <br />
rights to it passed to Intel. It has a good reputation in the market as <br />
lots of technical developments in OpenEmbedded have come via Poky.<br />
<br />
LDAT - The build system developed and used by Wind River. This is not an open <br />
solution at this time but could become open so is worth evaluating. Its <br />
strength is that it has a large feature set and is widely used by Wind River <br />
customers. Its makefile derived and shows signs of strain due to being <br />
constrained by the file format. It has been developed behind closed doors with <br />
a narrow focus and as such does not stand a good chance of wide community <br />
adoption if opened and hence is unlikely to become an industry standard.<br />
<br />
== Yocto Linux build system ==<br />
<br />
Acceptance of whichever build system is used by the wider community is <br />
essential to the project. We're in the fortunate position that Poky is an <br />
available option. The advantages of this choice include:<br />
<br />
* Its already well established and accepted in the community<br />
* It has commercial leanings<br />
* Intel can donate Poky to the Yocto Project<br />
* Its based on OpenEmbedded - industry leading<br />
<br />
On this basis it has been decided that Poky makes the best choice of build <br />
system for the Yocto Project.<br />
<br />
Where there are gaps in functionality we have the ability to change this.<br />
<br />
== Yocto Project Components ==<br />
<br />
If Poky is the build system for the Yocto Project, what other components are there? Should <br />
the Yocto Project perhaps be Poky?<br />
<br />
There is much more to the idea of the Yocto Project than just the build system. It makes sense to have <br />
namespaces for the components which is why Poky should remain just the build <br />
system. The other features/components that make up the Yocto Project include:<br />
<br />
* A place of collaboration - There are very effective strong communities in the opensource world such as xorg.org, kernel.org and gnome.org but there is no such place for embedded. The Yocto Projectcan provide this, primarily by providing a place where embedded focused software projects can be housed and discussions can be had.<br />
* A reference implementation: Yocto Linux - Any reference distribution/images created by Poky are something that is provided by the Yocto Project . This aims to reinforce the idea that Poky is the build system, not the end result of any given build of the metadata which instead would be Yocto Linux.<br />
* Board Support Packages - The Yocto Project can provide a place for people to publish its SoC BSPs.<br />
* Testing infrastructure - The Yocto Project can provide hardware to allow regular regression testing of the Poky metadata and demonstrate this publicly.<br />
* Partners - The Yocto Project also provides the entity which other parties can associate with to jointly improve and advanced the embedded Linux software position.<br />
* Standards - The Yocto Project can become the entity which sets the standards for the industry, aiming to be the model of best practises.<br />
* Documentation - Another output possible from the build infrastructure is documentation of all the components where the source contains these. As part of the reference implementation it would be desirable and extremely useful for the community to have access to a set of documentation all in one place.<br />
<br />
More details on the individual components follows below.<br />
<br />
== Yocto Project Partners ==<br />
<br />
To succeed, Yocto Project needs to ensure people will use it and one way of doing this <br />
is through partners.<br />
<br />
Discussions between Wind River and Intel revealed that they share frustration <br />
over the structure of the Embedded Linux market as mentioned above. The <br />
fragmented nature of the market has a cost to them and also presents a barrier <br />
to entry and their build system LDAT is different to any other on the market. <br />
All their BSPs effectively have to be developed and maintained in-house at <br />
significant cost.<br />
<br />
Wind River see the Yocto Project as very desirable as it means everyone would share <br />
the non-differentiation and become more standardised. Creating a BSP standard<br />
reduces the amount of work they have to do in integrating BSPs themselves. For <br />
these reasons Wind River are keen to be a founding partner of Yocto Project. Where <br />
the Yocto Project solutions lack the features they need for this there is agreement <br />
to enhance it and its components like Poky.<br />
<br />
As the Yocto Project grows and becomes public, its likely more partners will emerge and <br />
this will make the project stronger.<br />
<br />
== Yocto Project Components: A place of collaboration ==<br />
<br />
The Yocto Project website is intended to house embedded related software projects since <br />
there currently isn't a good home for a lot of these. We already have a number <br />
of different projects which could be used to seed this site:<br />
<br />
* Poky (from Intel)<br />
* Poky Anjuta SDK integration (from Intel)<br />
* MeeGo Eclipse SDK integration (from MeeGo)<br />
* Pseudo - A replacement for fakeroot (from Wind River)<br />
* qemuGL - A project to allow GL passthrough in virtualsation (from Intel)<br />
* OProfileUI - an embedded targeted client/server profiling tool (from Intel)<br />
* Cross platform prelink tools (from Wind River)<br />
<br />
Anyone wishing to house the source code/mailing list/bug-tracking for an open <br />
source project furthering embedded technology would be free to do so on this <br />
site.<br />
<br />
== Yocto Project Components: Reference Implementation ==<br />
<br />
A reference implementation will be available from the Yocto Project website under the name of Yocto Linux. These will <br />
be packages, images and an SDK/toolchain generated by Poky supporting the range of <br />
reference hardware we're promoting. For IA, this means we'd have images <br />
capable of being run under emulation in QEMU as well as having support for a <br />
suitable selection of our reference boards, particularly the SoCs chosen from <br />
our BSP selection. <br />
<br />
For other architectures we will provide reference images suitable for running <br />
under emulation as proof we are architecture independent but Intel will not <br />
provide builds for other specific platforms. If other partners join the <br />
project and undertake to maintain platforms on other architectures they are <br />
free to do so however.<br />
<br />
It is worth highlighting that the reference distribution and images created by <br />
Poky are something that is provided by the Yocto Project. We should reinforce the idea that <br />
Poky is the build system, not the end result of any given build of the <br />
metadata. The images and packages on the Yocto Project website are also a reference <br />
implementation which others are then free to build off.<br />
<br />
At any given time there is likely to be a stable release version of Yocto Linux <br />
available and also packages and images build from the master branch as part of <br />
automated testing. These are provided to demonstrate the status of the <br />
project, that everything is working and allow people to test new features. Its <br />
expected that product development be done based on stable release branches and <br />
if cutting edge features are required, these will be ported to the last stable <br />
release either by Yocto Linux maintainers if there is a widespread need, or on an <br />
individual basis if not.<br />
<br />
The benefit of having this reference implementation available is that anyone <br />
wishing to do embedded development has a known good place to start it from. By <br />
sharing this common base, solutions to any issues can be shared, faster <br />
development and time to market is possible, a strong community is formed and <br />
there is a common future forward migration path.<br />
<br />
== Yocto Project Components: Board Support Packages (BSPs) ==<br />
<br />
Currently there is no standardised way of publishing a BSP for a given <br />
platform either in the location its made public or the format. It is a <br />
massive problem in the embedded marketplace and nobody has as yet found a way <br />
to deal with this well. ARM is a particularly bad example with hundreds of <br />
different kernel trees, let alone userspaces. A given ARM platform is unlikely <br />
to work well with a standard mainline Linux kernel and whilst effort is being made to change this, it has not yet succeeded.<br />
<br />
The ideal situation would be having one central place where up to date code for <br />
a given platform can be found, both in the form of a kernel but also the support <br />
utilities and extras that platforms have.<br />
This needs to provide complete support for that platform including firmware and <br />
other userspace components that might be needed to make best use of the hardware features.<br />
<br />
The Yocto Project proivdes a standardised place and standardised format to do <br />
this. The exact format will be <br />
determined by the needs to the platforms but will be generic enough that an <br />
industry BSP standard could be established as a result.<br />
<br />
== Yocto Project Components: Testing Infrastructure ==<br />
<br />
One area many embedded build systems fall down is that their core developers <br />
can make them work but a newcomer to the project cannot. These systems by <br />
their nature are extremely complex and its essential they are regularly and <br />
extensively tested. There are two forms of testing that are desirable:<br />
<br />
Incremental - This provides an "acid test" of the last change made to the <br />
metadata. Its designed to run relatively quickly and test the change but not <br />
exhaustively or from scratch. If the tests succeed, its expected that there is <br />
a 95% chance the change did not cause any regressions. It also checks this <br />
change builds against an existing build. The developer can expect a warning <br />
about problems with a change quickly from these tests.<br />
<br />
Full - This is a test of the metadata as a whole from the ground up and <br />
ensures that the system is self consistent. Its designed to prove there was no <br />
regression but obviously the tests take longer to run.<br />
<br />
Its expected that incremental tests will happen on every commit to the <br />
metadata and that full testing will happen once every 24 hours at a minimum. <br />
Its also desirable that in future, separate branches can be tested outside of master and only merged into the main branch when a test suite completes.<br />
<br />
By doing this publicly, we're forced to keep the metadata buildable, <br />
consistent and people can see that we do this and care about the quality of <br />
what we're doing.<br />
<br />
Eventually it would be desirable to also test the build output of the system <br />
either under emulation or on the real hardware in the form of "board labs". <br />
There is an significant capital expense of setting these up as well as a <br />
current lack of software to support their use. It would however fit well in <br />
the Yocto Project testing infrastructure if we can reach a point where this is <br />
practical.<br />
<br />
== Yocto Project Components: Partners ==<br />
<br />
Partners are an important part of the Yocto Project as we want to defragment the embedded <br />
market and we can't do this if we don't build relationships with others. Its <br />
one of the key areas many other efforts in this marketplace fail as they tend <br />
not to cover the needs of the majority of the community.<br />
<br />
The main criteria for becoming a supporting partner will be agreeing to <br />
standardise working practices in line with the Yocto Project's objectives and most likely <br />
starting to use it as a standard. This may also involve offering support and <br />
development of its tools and infrastructure.<br />
<br />
In return partners benefit from the defragmented embedded market and jointly <br />
improve and advanced the embedded Linux software position.<br />
<br />
== Yocto Project Components: Documentation ==<br />
<br />
Whilst there is a wealth of information online about given projects, nobody <br />
has managed to effectively document a complete Linux software stack. The <br />
reasons is related to the size of the undertaking and the effort required to <br />
maintain it.<br />
<br />
Through the Yocto Project build infrastructure its possible that documentation <br />
generation could be largely automated. We'd have to find a way to bind all the <br />
separate pieces of documentation together but I think this is solvable <br />
problem.<br />
<br />
This coherent and up to date source of documentation would be another feature <br />
of the project provided to the community as part of our reference <br />
implementation. There would be a documentation collection corresponding to <br />
each release as well as a version corresponding to the latest master branch.<br />
<br />
An added benefit of this would be that individual software projects would be <br />
encouraged to put their documentation into order if they could see a high <br />
profile consumer of it which is inline with the Yocto Project's objectives of <br />
standardisation and improving the embedded ecosystem.<br />
<br />
<br />
== Build System - More details ==<br />
<br />
The structure of OpenEmbedded and Poky are specifically tailored to the needs <br />
of the embedded market space. One of the main ways this happens is the <br />
powerful way the metadata is split into separate configuration areas:<br />
<br />
: “Recipe” - details of a software package<br />
<br />
The recipe represents individual software components of the system, usually <br />
corresponding to a project which then goes on to make a release tarball. The <br />
recipe contains information on where to get this source code, how to extract <br />
it, information on any tweaks it may need for known issues (patches), what <br />
configuration options this software has and how to apply them, how to compile <br />
it and how to extract and split the output into packages.<br />
<br />
There can be one definition of a software project which is them shared by <br />
definitions for specific version releases of the software.<br />
<br />
: “Distro” - policy of the resulting system<br />
<br />
The distribution configuration is concerned with policy decisions such as <br />
which ABI to use, which versions of software should be preferred and is a <br />
representation of choices available and the values selected.<br />
<br />
: “Machine” - details of a specific hardware target<br />
<br />
The machine entities are information about particular hardware targets. They <br />
can be more general such as "netbook" or provide information about specific <br />
hardware like a Sharp Zaurus handheld SL-C3000 (spitz). These given <br />
information about the capabilities of the hardware such as the presence of a <br />
keyboard, touchscreens, displays, audio capabilities, I/O interfaces and so <br />
on. Also details about the best formats to provide images for the device can <br />
be contained here.<br />
<br />
This information is used by the system to customise output to work well on <br />
specific hardware.<br />
<br />
: “Image” - groups of software packages<br />
<br />
These are package groups which provide a working end result. "Sato" images <br />
contain all the functionality required to boot the Sato UI for example. A <br />
console image contains enough to boot a system to a console shell prompt. The <br />
contents of an image will depend on information from both the distribution and <br />
machine configurations.<br />
<br />
Each of these functionality areas are independent of the others and one can be <br />
changed or customised separate from the others. Bitbake through the structure <br />
of the metadata is able to combine the information from each section to <br />
provide a specifically tailored end result.<br />
<br />
The second powerful feature of the metadata structure is the overlay or layer <br />
capability. By combining several layers of metadata, a basic set of <br />
functionality can be extended or customised at multiple levels allowing a <br />
basic core to be extended and customised for different uses.<br />
<br />
For example we could have the following metadata stack:<br />
<br />
* Core Poky Metadata<br />
* MeeGo specific Overlay (adding the MeeGo UI software packages)<br />
* Vendor specific BSP (adding support for a particular hardware platform)<br />
* Commercial Overlay (provided by say Wind River adding commercialisation to the underlying layers)<br />
* Customer Specific Overlay (adding customisations only relevant to the customer)<br />
<br />
At each level, features can be added and underlying layers can be customised <br />
without duplicating code. The changes anyone makes also remain clearly <br />
isolated from the underlying system meaning they're clearly identifiable and <br />
can easily be ported to newer versions of other layers such as the core <br />
metadata.<br />
<br />
This structure encourages reuse of code and sharing and collaboration of <br />
metadata. An objective is to make the core as useful as possible so over time <br />
code initially developed as upper layers will tend to head towards the core <br />
where it makes sense. There will be functionality blocks such as "meego" which <br />
make sense as an overlay in their own right and customisations which will only <br />
ever apply to an end user's application too and this structure supports them <br />
all well.<br />
<br />
<br />
== Build System - Configurability ==<br />
<br />
Due to its modular nature, OE and Poky are very much infrastructures rather <br />
than monolithic projects. Any one component is usually isolated from the rest <br />
of the system meaning that if some area is found to need improvement, this can <br />
happen and the technology can move forwards without impacting other areas of <br />
the system. Pretty much everything is configurable.<br />
<br />
Implicit assumptions in the system have been carefully avoided. Issues such as <br />
output package format(s) or output image format(s) are abstracted such that <br />
multiple outputs are available and future developments can be added too, very <br />
easily. This makes the system very adaptable to almost any situation at a <br />
relatively low cost compared to other systems.<br />
<br />
== Build System - Cross compiling and multi architecture ==<br />
<br />
Firstly, it needs to be realised that the build system used has to be a multi architecture <br />
system. If it is specific to a single platform such as IA, it will <br />
automatically be ruled out of the embedded market and the community focus <br />
which we'd like to see will not happen. It therefore makes sense to have a <br />
multi architecture system.<br />
<br />
Regardless of architecture issues, for embedded systems its always likely <br />
there will be some differences between the build system's configuration and <br />
that of the target systems. This may be different configuration options, <br />
compiler flags, package versions and many other possible differences, it's <br />
impractical to even list them all.<br />
<br />
As such some way of isolating the target system from the build system is <br />
essential. The ways of doing this have been a topic of discussion for many <br />
years and will continue to be. Various approaches such as chroots, emulated <br />
environments, bare cross compilation and cross compilation using sysroots are <br />
all possibilities.<br />
<br />
In the general multi architecture case the build system is most likely <br />
different from the target architecture. This can apply on IA with a 64 bit <br />
build system building for a 32 bit target and vice versa. Since emulation and <br />
chroot aren't always possible or reliable, OE and Poky are a cross compiling <br />
build system making the best use of new cross compilation technology such as <br />
sysroots as it becomes available.<br />
<br />
In the embedded space, cross compilation is considered standard practise and <br />
widely accepted. The difficulties of cross compiling are also continually <br />
being reduced with new technology.<br />
<br />
== Build System - Any downsides? ==<br />
<br />
The biggest downside of OE/Poky by far is the shear complexity of the inner <br />
workings of the systems. They have been designed to be powerful and <br />
comprehensive which means there is a steep learning curve to a true deep level <br />
understanding of them. There are also several concepts which are different to <br />
a traditional 'desktop' Linux system.<br />
<br />
Poky has been at the leading edge of making the systems easier to use and is <br />
designed such that anyone with some basic Linux knowledge should be able to <br />
download it and build a Linux system from scratch. It also has a comprehensive <br />
manual covering many of the questions a new user to the system has. As always <br />
there is room for improvement but there is a strong foundation to build on.<br />
<br />
== Build System - Vendor Use Cases and Development Process ==<br />
<br />
The end result most vendors require are software "images" which then can <br />
install onto the end products. In some cases these will be field upgradable <br />
either through placing a new image onto the device in totality or in some <br />
cases though package upgrades in a more traditional PC Linux distribution <br />
style. In order to reach this goal there are several stages of development and <br />
the Yocto Project infrastructure needs to support them through them all:<br />
<br />
: Prototyping - The end hardware is probably not available yet but a quick <br />
mockup needs to be possible. This may be using CRBs, possibly customised to <br />
demonstrate key hardware features of the end device or it could be done using <br />
virtualisation.<br />
<br />
: Hardware Development - The system needs to allow for testing of new hardware as its developed.<br />
<br />
: Software Development - The system needs to allow development of the software <br />
that will be used on the final device, often before the final hardware is <br />
available. Some developers will be interested in the broad system and how all <br />
the pieces build and fit together, others could just be application developers <br />
interested in developing a single application. Both sets of developers must be <br />
supported.<br />
<br />
Poky itself fulfils some of these needs but not all of them. There are some <br />
cases having the full build system available is overkill for a specific <br />
developers needs. The counterpart is the SDK.<br />
<br />
== Software Development Kit (SDK) ==<br />
<br />
The SDK is a standalone output from Poky which consists of a sysroot <br />
representing a target system and some tools which allow the developer to build <br />
further software to work with that sysroot. Since we have little control over <br />
the system the developer will be using the SDK on, a standalone cross compiler <br />
and cross build tools are provided with the SDK to isolate the two systems in <br />
the same way Poky itself does.<br />
<br />
Using this toolchain the developer can build applications and libraries that <br />
will work with their target platform. Whilst usable from a shell, the SDKs are <br />
also capable of being used from within IDEs such as Eclipse and Anjuta at the <br />
preference of the developer.<br />
<br />
By having the SDK it further reduces the barriers to entry of developing <br />
applications for embedded systems since the developer does not have to use the <br />
build system itself. There is however a migration path should the developer <br />
require to become more involved with the build system itself.<br />
<br />
== Current Status and Areas for Development ==<br />
<br />
The Yocto Project itself does not currently exist and needs to be established as detailed <br />
above. OE and Poky do exist and are powerful and already extensively developed <br />
but there are some gaps in functionality which there are some gains by <br />
addressing:<br />
<br />
* By filling functionality gaps it promotes OE/Poky/Yocto Linux as the standard in the marketplace<br />
* By providing this technology first in Poky, it promotes Poky and Yocto Linux <br />
* Some functionality is required to enable adoption of commercial solutions vendors such as Wind River where features they currently enjoy in systems like LDAT are unavailable in Poky.<br />
<br />
The Yocto Project itself goes a long way to solving a number of problems by pulling pieces <br />
like the various SDK plugins and other technologies into one place which can <br />
then be consistently documented. There is also a list of features specifically being worked on for Poky and Bitbake.<br />
<br />
== Yocto Linux Development Team Structure ==<br />
<br />
To fulfil its objectives we anticipate the need for 3 different teams of <br />
people working on the project:<br />
<br />
=== Embedded Core Team ===<br />
<br />
This team provides the core guidance on the project and consists of the <br />
architect and technical direction, programme management, some developers <br />
working on the overall picture of the project along with people responsible <br />
for overall documentation and QA.<br />
<br />
=== Embedded Tools and SDK Team ===<br />
<br />
This team is responsible for improvements to the tools and infrastructure. <br />
They would be implementing features like the server mode of bitbake and its <br />
integration to something with similarities to Buildbot, the Eclipse and Anjuta <br />
plugins and SoC support through the Yocto Linux SDK<br />
<br />
=== Distribution Engineering ===<br />
<br />
This team is much more focused on the day to day maintenance of the metadata, <br />
upgrading versions when required to keep Poky at the forefront of technology, <br />
watching for security updates, integrating any relevant technology and <br />
managing metadata releases and QA.<br />
<br />
The Yocto Project team does not directly cover development of BSPs and SoC drivers. The teams <br />
will advise on integration of code into Yocto Linux in parallel with its submission <br />
of upstream and assist with any issues that arise however.<br />
<br />
<br />
Author: Richard Purdie, November 2009<br />
(names have been adapted in the document subsequently for clarity)</div>WikiSysop