nyuuzyou/wikis huggingface dataset:
Architecture-ABI

== Introduction ==
There are currently many official and unofficial ABI -- Application Binary Interfaces -- in use within embedded Linux projects. The following is an attempt to lightly document what the individual architecture ABI consist of, without going into too many details..
Many of the following ABIs have grown organically based on specific processor designs and optimization levels. For the most part the processor optimizations are ignored in these descriptions, unless otherwise mentioned.
Additional references, CPU optimization compatibility and suggested canonical architecture namings may be provided.
== ABI Summary ==
The following is a list of ABIs that are in common usage. Some of the ABIs discussed in the following sections will not appear in this table if they are legacy.
Arch	ABI 	Endian 	Compatibility
ARM 	EABI	Big Endian 	
ARM 	EABI	Little Endian	
== ARM ==
=== ABI ===
apcs-gnu a.k.a. OABI - The original ARM ABI.
It has two variants, an emulated hardware floating point, and a soft floating point variant. The legacy ABI should no longer be used in embedded projects and has more or less disappeared. The legacy ABI is not compatible with the EABI.
You can detect the ABI if the result of objdump -x contains [APCS-32]
The legacy abi can be enabled by using "-mabi=apcs-gnu"
----
EABI - The new "Embedded" ABI by ARM ltd. This is otherwise known as "the ABI for the ARM Architecture".
The new EABI specifies a single ABI that works in various hardware floating point and software floating point configurations as well as Thumb interworking. Overall structure packing is better, a more efficient syscall convention is provided.
You can detect the ABI if the result of objdump -x contains [Version4 EABI]
=== Processor Variants ===
The gnu-canonical architecture for arm is in the format:
 armv<version><capabilities>-os-linux-gnu-eabi
The gnu-eabi indicates that it is the newer EABI ABI.
The ARM core versions include:
* armv4
* armv5
* armv6
* armv7
The ARM processor capabilities indicate:
* el - little endian (optional)
* eb - big endian
* t - thumb/thumb2
* j - java
This would result in something similar to: armv7teb, for an ARM 7 core, with thumb capabilities, running in big endian mode.
In addition processors may include specific optimizations that change which CPUs a compiled program will run on, these include:
* VFP instructions
* NEON
* Thumb/Thumb-2 instructions
== IA32 ==
== MIPS ==
== Power ==
Archive

This is the graveyard for old articles. Anything you find here refers to old Yocto Project releases. Peruse at your own risk. 
If you find an article your believe should not have been sent to the graveyard, please contact Henry Bruce.
* How do I
* Contributors
* meta-intel-2.0-dizzy-1.7 release planning
* Training
* YoctoCalendar
* Image Recipes
* Hob Web UI
* SDK Generator
* Orphaned Pages (350 and counting...)
Arduino Single power control unit

== The Justification ==
The Arduino Single power control unit was created for controlling a relay that is able to turn on/off the devices that it powers like the Yocto DUTs. Such need has arisen due to a clean power-off has not been always reliable.
== The hardware part ==
=== The circuit ===
In order to build a power cutter using a relay module, one must follow the circuit provided.
==== The required hardware ====
* 1 BJT transistor 2N2222A
* 1 3.3 kOhms resistor
* 1 1N4007 diode
* 1 relay module (RAS-0510)
* 1 Protoboard or perforated PCB (min 4.5x4.5 cm)
* 1 Two positions terminal block
* 1 male outlet connector and 1 female outlet plug
* 14AWG Wire (as needed)
=== The arduino 101 ===
==== Configuration for power cutter cables upon Arduino 101 ====
* 5V (from the board)
* GND (from the board)
* Signal (min 3.3V max 5V, from GPIO 13 of board)
== The software part ==
It is required devauto module simplepwsc to control this single power unit. Upon the source directory of this module can be found gen_ard_101.ino to flash the arduino 101
AutoBuilder/Adding Automated Tests

==Preparation==
Adding automated tests to the AutoBuilder assumes that the testing is done in either of the following formats:
*OpenEmbedded Selftest format
*Bitbake Runtime tests format
The AutoBuilder interfaces with the test tool via a calling command. Such test calling command is used to start executing a given set of tests. The test set description can come in the way of a configuration (file, variable, argument, etc) and it ultimately explicitly lists which tests are to be run. It is an expectation of the test tool that it procures the execution of the list of tests that has been specified at the moment of calling the starting command. 
===Sample Test for Instructions===
For the purpose of this guide, the following test calling command will be used:
$ oe-selftest -r bbtests.BitbakeTests.test_warnings_errors
The test tool used is in the OpenEmbedded Selftest format and the calling line selects a single test from the BBTests suite. The reason for this choice is merely simplicity for writing this guide. 
You can see the code of this particular test here (referencing the Krogoth release):
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/bbtests.py?id=krogoth-15.0.0#n58
There should be about 5 lines of code there, the test can be simply explained as: execute a bitbake build from a file that doesn't exist and verify that it shows an error. It's a negative test.
====Sample Test Output====
Getting familiar with the output of the test is a good idea. Preparing the environment for running such test can be seen at the Oe-selftest#How_to_use section. 
Once the test is run at the command line, the following terminal output is presented:
$ oe-selftest -r bbtests.BitbakeTests.test_warnings_errors
2016-06-15 13:55:30,964 - selftest - INFO - Running bitbake -e to get BBPATH
2016-06-15 13:55:32,027 - selftest - INFO - Checking that everything is in order before running the tests
2016-06-15 13:55:33,073 - selftest - INFO - Running bitbake -p
2016-06-15 13:55:36,228 - selftest - INFO - Loading tests from: oeqa.selftest.bbtests.BitbakeTests.test_warnings_errors
2016-06-15 13:55:36,230 - selftest - INFO - Adding: "include selftest.inc" in local.conf
2016-06-15 13:55:36,230 - selftest - INFO - Adding: "include bblayers.inc" in bblayers.conf
2016-06-15 13:55:36 - test_warnings_errors (oeqa.selftest.bbtests.BitbakeTests) ... ok
----------------------------------------------------------------------
Ran 1 test in 0.782s
OK
2016-06-15 13:55:37,012 - selftest - INFO - Finished
2016-06-15 13:55:37,012 - selftest - INFO - Removing the include from local.conf
2016-06-15 13:55:37,012 - selftest - INFO - Removing the include from bblayers.conf
=== an AutoBuilder to Run the Test ===
An AutoBuilder will be needed to run the testing, for letting the AutoBuilder know what you want to test, a config-set is required. Once you create the config-set, an AutoBuilder is needed to test and run it when finished.
==== Basic AutoBuilder Knowledge====
====Setup an AutoBuilder Instance for Testing====
==Test Enabling Steps==
===Write the Build Set===
====Include the Test in a Build Step====
===Test the Build Set===
AutoBuilder Maintenance

== Overview ==
An AutoBuilder system consists of a controller and one or more workers. The controller reads configuration files, presents a simple web user interface and sends build step commands to the worker(s). The worker refers to the machine performing the actual build.
Note: when making any changes on an AutoBuilder cluster, be sure you are doing it as the pokybuild user. That is, ssh into the remote machine with your normal login account, the run 'sudo -iu pokybuild'.
=== Update the List of QA Email Recipients ===
Emails are now sent to a dedicated email list so people can subscribe as needed.
== Resources ==
* AutoBuilder Main Page
* AutoBuilder Cluster Setup
BKM: improve qemu performance

Link title= improve qemu performance =
Qemu in yocto is emulator, and is slow when running huge task inside. E.g. running yocto build inside qemu. This article illustrate possible performance improvement to accelerate it
== Enable KVM ==
If you have processor with VTx support, you can enable KVM so that virtualization rather than emulation is used for performance. Pls. refer following:
* How to enable KVM for Poky qemu
== Add big memory ==
Sometimes, workload inside qemu requires huge memory. Fail to do this lead performance drop. So pls. add enough memory to qemu via -m 2048 (2G).
== Enable SMP ==
If workload inside qemu is CPU-intensive, you can enable smp:
* enable smp configuration in yocto kernel
* enable smp option for qemu, like -smp 4 to give 4 vcpu to guest.
qemu built from yocto may have some bug that only 1 vcpu is truly used by guest(You can use top -d1 inside guest to see only 100% CPU usage). Pls. switch to the qemu in the linux distribution, say ubuntu, as one workaround.
== Add extra disk space ==
If workload inside qemu is disk-intensive, it may requires huge disk space. You can set up NFS server or add extra disk image, which is preferred as NFS server introduce extra network workload.
Following steps to create a new disk image(10G) with ext3 file system:
 $ sudo dd if=/dev/zero of=b.img bs=1G count=10
 $ sudo losetup /dev/loop0 b.img
 $ sudo fdisk /dev/loop0
 Then create one new single partition
 $ sudo mkfs.ext3 /dev/loop0
 to create ext3 file system
 $ sudo losetup -d /dev/loop0
append this disk image to qemu via -hdb(need further changes if need virtio block device)
== Create network environment ==
Default qemu in yocto talk with host via simple 192.168.7.X, you can use bridge to make the guest act as one true machine, E.g download source code from outside. Pls. see http://www.linux-kvm.org/page/Networking#public_bridge for details
== Enable virtio block and network device ==
Virtio (block/network) device is a para-virtualized device for kvm guest. It is different from normal emulated hard drive, because it is simply faster. 
* enable yocto kernel configuration
 +CONFIG_VIRTIO=y
 +CONFIG_VIRTIO_PCI=y
 +CONFIG_VIRTIO_BALLOON=y
 +CONFIG_VIRTIO_RING=y
 +CONFIG_VIRTIO_NET=y
 +CONFIG_VIRTIO_BLK=y
* change qemu block device parameter from "-hda <your_disk_image" to -drive file=<your_disk_image>,if=virtio
* modify qemu NIC parameter: change the -net nic option to include model=virtio
Following is one example
 -net nic,model=virtio,vlan=0 -net tap,vlan=0,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -drive file=/home/source.img,if=virtio -drive file=/home/build.img,if=virtio
== Enable VTd to for NIC/Block device ==
Enable VTd with KVM can directed assign PCI device(like NIC or USB disk) to guest, then achieve almost native performance. Pls. make sure your chipset and bios support VTd.
Details is to be coming soon:)
BSP Team Bug Triage

= New Team bugs (No Priority) =
= New BSP bugs (No milestone) =
= High/Medium+ Bugs =
= NEEDINFO =
= REOPENDED =
= Old Milestone =
= YP 2.5 remaining BSP Team Enhancements =
= Amber Bugs =
= Anuj Bugs =
= Cal Bugs =
= Juro Bugs =
= Stephano Bugs =
= Bruce Bugs =
BSPs

* Yocto BSP One-Stop Shop (Documentation Overview, Getting Started, FAQs, and more)
* Poky Contributions
* Poky NFS Root
* Wind River Kernel
* Merging Packages from OpenEmbedded
* How to turn on Poky Audio on Netbook
* How to Build Target Application in the Host Machine
* How to enable KVM for Poky qemu
* Yocto BSP Summit Presentation
* Yocto BSP Tools Documentation
* Transcript: from git checkout to qemu desktop
* Transcript: from git checkout to meta-intel BSP
* Transcript: Using the Yocto BSP tools to create a qemu BSP
* Transcript: Using the Yocto BSP tools to manage kernel patches and config items
* Transcript: Using the Yocto BSP tools to create a meta-intel BSP
* BKM: starting a new BSP
* Transcript: creating one generic Atom BSP from another
* BKM: improve qemu performance
* Last Known Good Commits for meta-intel
* meta-intel Release Process
BSPs/FRI2

__TOC__
== Resources ==
Latest FRI2 README
== Tips ==
Use this space to share tips about using the FRI2. If you didn't find it in the README and it took you longer than 5 minutes to figure it out, consider placing it here and we can work it into the README as appropriate.
=== Unable to view HDMI output on your monitor ===
Some HDMI monitors do not appear to work with the HDMI output from the FRI2. Which displays work and which do not can be unpredictable; it may even be the case that individual monitors of the same make and model may work while others may not.
As a workaround you can connect the FRI2 to the DVI connection on your monitor using an HDMI to DVI adapter.
=== Obtaining the ti_3410.fw file needed by ti_usb_3410_5052 ===
Debian (and perhaps other Linux distros) do not package ti_3410.fw (no, not even in lfirmware-linux-nonfree). The following bash script will use git to obtain just the one file from kernel.org and move it to where "modprobe ti_usb_3410_5052" will find it:
 #!/bin/bash
 sudo apt-get install git
 git clone -n git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git --depth 1
 cd linux-firmware
 git checkout HEAD ti_3410.fw
 sudo cp -p ti_3410.fw /lib/firmware
The script is tested on Debian with 3.1.0 kernel and will need to be modified if your system uses RPM and/or does not follow the standard filesystem hierarchy.
Note that Ubuntu and Fedora both package it with the linux-firmware package and Ubuntu also includes it in the various linux-image packages.
== Known Issues ==
=== Warning at arch/x86/kernel/apic/ipi.c ===
 WARNING: at [...] linux-yocto-3.2.18+git1+5b4c9dc78b5ae607173cc3ddab9bce1b5f78129b_1+76dc683eccc46804729a76b9d2fd425ba540a483-r1/linux/arch/x86/kernel/apic/ipi.c:109 default_send_IPI_mask_logical+0xa4/0xe0()
 Hardware name: Fish River Island II
 empty IPI mask
 Modules linked in:
 Pid: 1, comm: swapper/0 Not tainted 3.2.18-yocto-standard #1
 Call Trace:
 [<c103b8d3>] warn_slowpath_common+0x73/0xa0
 [<c1018234>] ? default_send_IPI_mask_logical+0xa4/0xe0
 ...
This appears to be a known issue with how IPIs are handled within the generic SMP infrastructure. A fix is being discussed on LKML, but the warning appears to be benign.
BitBake/GUI

== Introduction ==
Thanks to BitBake's client/server split there are several possibilities for graphical interaction with BitBake. At this time most development effort is being put into the hob GUI, which aims to be a general-purpose graphical tool for interactive BitBake sessions. 
== Current GUI's ==
There are currently three GUI's in BitBake, the most recent of which is in the "extremely prototype" phase of development.
depexp - a graphical dependency explorer
use-case: view task dependencies in an interactive GUI
run with: bitbake -g -u depexp <some-target>
goggle - a graphical build viewer 
use-case: watch build progress using a GUI, potentially easier to follow than terminal output
run with: bitbake -u goggle <some-target>
hob - a graphical image creator
use-case: create custom images without having to edit files by hand
run with the wrapper script from a sourced build directory: hob
(this runs: 'bitbake -r conf/hob-pre.conf -R conf/hob-post.conf -u hob' after ensuring the passed configuration files exist)
== Ideas? ==
Ideas for future GUI work are being collected here
BitBake/GUI/Future

Here are some ideas for future GUI developments for BitBake:
* kernel config UI - UI tooling for simply enabling KConfig options without resorting to the "hacky" way. Needs research and communication with Kernel team.
* BitBake config editor - build on the oetypes stuff to enable a UI which can edit arbitrary BitBake configuration variables.
* image writing - graphical tool to take output of BitBake run and do the right thing to put it on some media for use. Specifically the crazy stuff to get atom images on a usb stick.
* Filter columns on desired value i.e: select desired license and only see recipes which match that
BitBake/GUI/Hob

The purpose of the tool is to allow the user to create and build a custom image as well as enabling parameters of the build to be configured.
I've tried to apply the principle of least surprise and tried to make the app fit in on a Gnome desktop by following their HIG. One possibly unexpected outcome of this is that you modify Preferences which equate to values in local.conf
See planned and unplanned tasks for the hob at the WIP page.
There's even a Yocto bugzilla component for the 'image creator':
http://bugzilla.yoctoproject.org/buglist.cgi?product=Build%20System&component=HOB&resolution=---
BitBake/GUI/WorkInProgress

Note: this page is for tracking imminent/in progress work.
== Unplanned extra features - schedule at next map day ==
* (Re-)Enable removal of packages http://bugzilla.yoctoproject.org/show_bug.cgi?id=1450
* Show contents of images & tasks (per community feedback) http://bugzilla.pokylinux.org/show_bug.cgi?id=991
* Show more information for selected package (per community feedback) http://bugzilla.pokylinux.org/show_bug.cgi?id=992
* add context menus to build view
** view logs
** show log directory
** view log for task
* add context menus to package view
** "Rebuild-from" with a submenu for each task of the build; fetch, unpack, compile, etc.
* hobhandler as a proxy to the server has a code smell
* Add GUI to set mirror variables (SSTATE, PREMIRROR, ?)
* "Overlay" files, extra files to be installed into the rootfs at image generation time
** Custom ROOTFS_POSTPROCESS_COMMAND
* Display and change IMAGE_FEATURES
* Consider allowing dragging a package from the list to the contents area
BitBake/UserManual

== Introduction ==
The current BitBake User Manual, as of Dec. 31, 2012 is quite out dated. This page serves a a place to collect ideas for revisions that are required to bring the User Manual up to date.
== Current TOC ==
The chapter layout of the BitBake User Manual is currently:
# Introduction
# Metadata
# File Download Support
# The bitbake command
=== Working TOC ===
This is the new document structure I'm working with:
#Introduction
##History and Goals
##Concepts - This section will introduce the relationship between the BitBake executable and the metadata file types. I'll introduce Layers here as well.
#BitBake Quickstart - this Chapter will include 2-3 real world examples.
## Hello World - documents the development of a Hello World BitBake example, exclusive of OE or Yocto.
## Building an OE Image - documents how to build a reference image based on an OE layer, probably core-image-minimal.
## Building a Yocto Project Image - similar to the latter, but specific to a Yocto Project image.
#Metadata - this chapter will build on what already exists in the manual, adding context, more examples, etc. Variable will be organized into applicable metadata file types.
##Conf Files
##Recipes
##Classes
I'll likely delete the File Download Support Chapter, and The BitBake Command chapters and integrate that information into the latter chapters.
== What to Include? ==
* As pointed out by rday, the patch function is inherent to oe-core, while the fetch function is inherent to bitbake. So can one be discussed without the other?
* Concepts:
**Explain each step in the bitbake process thoroughly.
**Provide context to commands. The why, not just the how.
== Lessons to Include ==
* The Bitbaked Hello World
** Build on the work by Eren Turkey and the original tutorial at the OpenEmbedded wiki.
* Using the Bitbake Env Utility
== Random observations by rday ==
* While BitBake fetcher supports numerous fetching protocols, only half of them are even used so I would simply ignore the unused ones. I made a bunch of notes on fetching here.
* Section 2.2.1 of current BitBake manual opens with discussion of "VAR_<override>_append" construct; that appears to be simply broken and unused. I would ignore it. The other form, "VAR_append_<override>" is, of course, used massively and should be documented.
* Variables that probably deserve more coverage:
** BB_DANGLINGAPPENDS_WARNONLY = "1"
== Deprecated/weird/dead stuff ==
* All "proto=" should now be replaced with "protocol=" in SRC_URI, although the old form is still allowed but deprecated.
* All "pnum=" should now be replaced with "striplevel=" in SRC_URI for patches.
* Current BitBake manual shows a "this=ignored" parm for patches; total mystery what that means, nothing uses it, Chris Larson has no idea what it's for. Ignore it.
== Add Hob Documentation ==
With Hob getting better and better, it would seem appropriate to include a chapter in the Bitbake User Manual documenting it.
BitBake Internals WIP Docs

= PR Service and Fetcher Incremental Revision Notes = 
There are several problems the fetcher needs to solve when working with source control systems and package managers:
a) The version field (PV) needs to change if any of the underlying inputs from SRC_URI have changed revision. This is to allow new builds to occur when SRC_URI changes.
b) The version field seen by the package manager needs to increase in for changes in the metadata (which comes from the PR Service) in a way that sorts correctly and allows incremental package upgrades
c) The version field seen by the package manager needs to increase in for changes in SRC_URI in a way that sorts correctly and allows incremental package upgrades
To make this happen, several things happen:
a) In scm based recipes, SRCPV is injected into PV in the correct place. 
b) SRCPV contains a set of numbers that increase for each new revision, one per SCM source contained in SRC_URI.
c) If automatic revisions are enabled, SRCPV starts with the placeholder string "AUTOINC+"
d) The AUTOINC string is replaced with the correct version number during do_package and the PR service ensures these numbers increment.
e) An automatic incrementing number from the PR Service is appended to PKGR through the AUTOPR variable.
f) AUTOPR is only set during do_package when the packages are generated
Bug Product Triage

= Yocto Bug Triage AutoBuilder Searches =
= Yocto Bug Triage BitBake Searches =
= Yocto Bug Triage BSPs Searches =
= Yocto Bug Triage Eclipse Plugin Searches =
= Yocto Bug Triage Hob Searches =
= Yocto Bug Triage Kernel Searches =
= Yocto Bug Triage Meta-yocto Searches =
= Yocto Bug Triage OE-Core Searches =
= Yocto Bug Triage Reference Searches =
= Yocto Bug Triage Sato Searches =
= Yocto Bug Triage Toaster Searches =
= Yocto Bug Triage Website Searches =
= Yocto Bug Triage Other Searches =
Bug Triage Archive

== Medium+ Bugs ==
== Medium+ Enhancements ==
== Medium+ Enhancements (Future) ==
== Medium+ Bugs and Enhancements by Owner !(Future, 3.99) ==
== Medium Bugs and Enhancements by Owner !(Future, 3.99) ==
== Low Bugs and Enhancements by Owner !(Future, 3.99) ==
== Major or Critical ==
== 3.99 Bugs by Owner ==
== 3.99 Enhancements by Owner ==
== Future Milestones by Owner !Unassinged ==
== Unassigned or Newcomer Bugs ==
== Non-Prioritized Bugs (Not Yocto) ==
== Non-Targeted Bugs (Not Yocto) ==