nyuuzyou/wikis huggingface dataset:
LAVA server vs Yocto HW automation testing

Lava server vs Yocto hardware automation testing 	Lava server vs Yocto hardware automation testing	Lava server vs Yocto hardware automation testing	Lava server vs Yocto hardware automation testing
Tested steps 	Lava 	Yocto 	Comments
Controlling a board via serial connection 	Y 	Y 	
Booting a board via serial connection and bootloader using Yocto images artifacts	Y 	Y 	
Able to schedule a test jobs to run at certain time 	N 	Y 	"Cron can be used in addition with lava CLI commands to trigger a test job"
Able to perform a full automated test cycle for a non serial connection board 	N 	Y 	"There is an issue with the test job which is exiting right after the master image ‘reboot’ command in order to boot into the test image as the master image ssh connection is lost and cannot run the next configu#FF6347 steps from the test job.Opened an enhancement for this at linaro but they told me that this feature will not be implemented for the dummy-ssh devices (https://bugs.linaro.org/show_bug.cgi?id=478)"
Able to view the test jobs results as tables 	Y 	N 	
Able to view the test jobs results as graphical reports 	Y 	N 	
Able to query old test jobs results 	Y 	N 	
Can use existing connection scripts for the tested boards 	N 	Y 	
Does not require additional packages for master image 	N 	Y 	Aditional packages needs for master image for ssh - sshfs connection
Can use existing test definitions 	N 	Y 	Runtime tests definitions needs to be manually added
Can use existing test jobs 	N 	Y 	Tests jobs needs to be manually created
Web based interface support 	Y 	N 	
Can accept test results from external sources 	N 	Y 	There is no way to submit results from the tested bsp to the Lava server
Authentication user support for the web based interface 	Y 	N 	
Able to use Yocto images artifacts 	Y 	Y 	
Can use the existing master image configurations 	N 	Y 	"We need to generate a pair of authentication keys between lava server and the master image – password less authentication from lava-server to the master image – root is requi#FF6347;Master image and test image must have the .ssh/authorized_keys configu#FF6347."
Launch Plan October 2010

==Pre-Launch To-Do List for Oct 25==
* Add your to do items & make sure launch checklist is good - ALL
* Add Yocto logo and favicon to the wiki - Richard
* Finish any last minute content changes - Scott
* Announcement blog post - Dave
* Final decision on where the FAQ lives & move it if necessary - Scott
* Create checklist - Dawn
* Get BSP Guide content finished - Scott
* Publish BSP Guide on website - Mike
* Upload release notes - Dawn
* Add Google Analytics to Drupal - Mike
* Publish FAQ - Scott
* Fix links to guides to open in a new window - Dawn
* Minor wiki cleanup - Dawn
* Confirm that I can remove this text from home page: "You’ve just landed on the Yocto Project home site." - Dawn
* Get rid of unverified next to blog author & see if we can display name instead of userid - Mike
* Need to figure out what to do about logging in to post comments - disable comments - Dawn / Mike
* Fix permissions so that anonymous users can't edit pages - Dawn / Mike
==Schedule for October 26==
* 7am UK / 11pm Pacific (Oct 25) - Code goes live and open websites (no announcements).
* 9am UK / 1am Pacific - Press release, announcements and conference presentation announcing Yocto
* 8pm UK / Noon Pacific - Dirk's presentation.
==Launch Checklist==
7am UK / 11pm Pacific
* Remove access control and redirection - Richard
** Remove password protection from yoctoproject.org (sub)domains - Richard
** Swap default site redirection and name for lists.* and wiki.* - Richard
* Make meta-demo public - Richard
* Remove password protection from autobuilder - Scott G.
* Upload final version of the eclipse plugin - Jessica
* Upload final Yocto release images and tarballs - Richard
* Remove access control from the Drupal website - Richard
* Final round of testing links to make sure they work - Dave
** http://www.yoctoproject.org/community/bugs - test bugzilla links
** http://www.yoctoproject.org/download - test all links, esp download / mirrors
** http://www.yoctoproject.org/community
** http://www.yoctoproject.org/community/discussions
** http://www.yoctoproject.org/community/documentation
9am UK / 1am Pacific
* Publish press release - Amanda
* Rebrand bugzilla with Yocto logo - Richard
* Post announcement to mailing lists - Dave
* Post to LWN - Dirk
* Post to Twitter account - Dave
8pm UK / Noon Pacific
* Dinner presentation - Dirk
Member Technical Contacts

This page tracks the official technical contributors to the YP core from each of the Yocto Project's member organizations. Note that many organizations provide more resources than just one, particularly in terms of hardware or specific feature support, which is why the Yocto Project is a de facto standard for building Linux for embedded systems.
Platinum Members
* Amazon: Richard Elberger <elberger@amazon.com>
* Arm: Ross Burton <ross.burton@arm.com>, Akanksha Jain <akanksha.jain2@arm.com>, Ellie Stanford-Reed <ellie.stanford-reed@arm.com>
* Boeing: TBD
* BMW: Mario Goulart <mario.goulart@bmw.de>, Nisha Parrakat <nisha.m.parrakat@bmw.de>, Philip.Lorenz <Philip.Lorenz@bmw.de>
* Cisco: Taras Kondratiuk <takondra@cisco.com>
* Comcast: Raj, Khem <Khem_Raj@comcast.com>
* Exein: Giovanni Alberto Falcione <giovanni@exein.io>
* Intel: apoorv sangal <apoorv.sangal@intel.com>, Anuj Mittal <anuj.mittal@intel.com>
* LG: Kyunglik Min <dp.min@lge.com>
* Qualcomm: TBD
* Wind River: Robert Yang <liezhi.yang@windriver.com>; Saul Wold <Saul.Wold@windriver.com>
* AMD/Xilinx: Mark Hatle <mhatle@xilinx.com>
* Garmin: Joshua Watt <Joshua.Watt@garmin.com>
Gold Members
* AGL: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>, Walt Miner <wminer@linuxfoundation.org>
* Huawei: TBD
* Linaro: Bill Mills <bill.mills@linaro.org>, Mikko Rapeli <mikko.rapeli@linaro.org>
* Microsoft: Paul Eggleton <paul.eggleton@microsoft.com>
* Renesas: Mr. Takamitsu Honda <takamitsu.honda.pv@renesas.com>
* Siemens: Chris Larson <chris_larson@mentor.com>, Wade Farnsworth <wade_farnsworth@mentor.com>
* Texas Instruments: Praneeth Bajjuri <praneeth@ti.com>
* Witekio: TBD
Silver Members
* Axis: Hakan Rick <hakan.rick@axis.com>, Peter Kjellerstedt <peter.kjellerstedt@axis.com>
* Bootlin: Alexandre Belloni <alexandre.belloni@bootlin.com>
* Dell: Michael Brown <michael.e.brown@dell.com>
* Founderiesio: Ricardo Salveti <ricardo@foundries.io>
* Konsulko: TBD
* Lineo Solutions: Masahiro Miyake <miya@lineo.co.jp>
* MontaVista: Armin Kuster <akuster@mvista.com>
* NXP: Lauren Post <lauren.post@nxp.com>, Tom Hochstein <tom.hochstein@nxp.com>
* Peridio: TBD
* RISC-V: TBD
* Roku: Cameron Esfahani <cesfahani@roku.com>
* Savoir-faire Linux: Christophe Villemer <christophe.villemer@savoirfairelinux.com>, Eloi Bail <eloi.bail@saviorfairelinux.com>, Jerome Oufella <jerome.oufella@saviorfairelinux.com>
* Smile: Yoann Congal <yoann.congal@smile.fr>
* ST: Christophe Priouzeau <christophe.priouzeau@foss.st.com>
Technical Partners
* OpenEmbedded: Philip Balister <philip@balister.org>
Note: a private mailing list exists with all individuals listed here, mainly to facilitate the communication and the organization of meetings. All technical discussions are encouraged to be made on the existing, open, project mailing lists. If you believe you need to be added to the private list, please reach out to the Yocto Project Community Manager.
Merging Packages from OpenEmbedded

The below are some stylistic guidelines to be aware of when importing recipes from OpenEmbedded (Classic).
Note: please be sure to always attribute OpenEmbedded when you take a recipe from there, even if it is changed heavily. Something like based on recipe from OE-Classic in your commit message should suffice.
* Consistent whitespace throughout the file
* File follows a roughly standard variable order
* Patches are all documented
* Use BBCLASSEXTEND where possible instead of -native / -nativesdk versions
* pkgconfig .pc files are correct and don't need manual mangling
** if its using pkgconfig.bbclass ensure the .pc files are correct, may need a patch. Sure sign is the .pc files have long paths in including the WORKDIR or sysroot paths. They should just have references like "/usr/lib/", i.e. target system paths and pkgconfig will automatically add in the correct sysroot paths as needed.
* No custom do_configure for autotooled projects
* Use "make install" where at all possible
* Remove any BBVERSIONS lines
* Use ALTERNATIVE_* Recipe metadata instead of update-alternatives command
For more practical information on migrating recipes see Migrating metadata to OE-Core over at the OE wiki.
Meson/UnknownCPU

= Unknown CPU Family =
== The Problem ==
OpenEmbedded uses the machine fragment of the GCC target triplet to identify the target architecture, but Meson uses the values returned by Python's platform.machine() which is based on the uname values. These don't match, so when cross-compiling we need to map the name when writing the Meson cross file. Also OpenEmbedded patches Meson to make an unknown architecture a fatal error instead of just a warning as during the build the warning won't be visible and bad CPU family setting can produce incorrect builds.
The known CPU families in Meson are listed at http://mesonbuild.com/Reference-tables.html#cpu-families.
When this mapping table isn't complete (for example, passing mipsel instead of mips) or the list in Meson needs updating (for example, new architecture) you'll get an error from Meson:
 Unknown CPU family mipsel, see https://wiki.yoctoproject.org/wiki/Meson/UnknownCPU for directions
== What To Do ==
In this situation you need to know two values: the OpenEmbedded architecture name (${TARGET_ARCH}) and the Python platform name. The platform name can be obtained in either a virtual machine or on real hardware:
 $ python3 -c 'import platform; print(platform.machine())'
 x86_64
As a worked example, consider the little-endian MIPS case. The TARGET_ARCH for a MIPS machine in little-endian mode is mipsel but Meson doesn't consider endian changes different CPU families so they're both mips. This is already in the CPU Family table so all that needs to happen is another case added to meson_cpu_family() in meson.bbclass. Please file a bug with this information, or ideally write a patch.
However if the problem is that you're working on an architecture that isn't in Meson's CPU Family list, then first please submit a bug to Meson to get the canonical platform name added, and then an OpenEmbedded bug if a mapping is required.
Meta-intel-2.0-dizzy-1.7 release planning

=== For reference here is the Yocto Project 1.7 release schedule===
* YP 1.7 M4 RC2 Build/QA test : Oct 8 – Oct 14
* YP 1.7 M4 RC3 Build/QA test : Oct 15 – Oct 21
* YP 1.7 M4 RC4 Build/QA test : Oct 22 – Oct 28
* YP 1.7 Release Final Publish : Oct 29 – Oct 31
=== Meta-intel 2.0 release schedule ===
* Meta-intel-2.0-dizzy-1.7 RC2 Build/QA test: Oct 8 – Oct 14
* Meta-intel-2.0-dizzy-1.7 RC3 Build/QA test: Oct 15 – Oct 21
* Meta-intel-2.0-dizzy-1.7 RC4 Build/QA test: Oct 22 – Oct 28
* Meta-intel-2.0-dizzy-1.7 RC5 Build/QA test: Oct 29 – Nov 4
* Meta-intel-2.0-dizzy-1.7 Release : Nov 5 – Nov 11
=== Remaining tasks for the meta-intel release ===
* Release branch and tags for QA use - Darren/Tom
* Per RC meta-intel build and QA test - Alex & IoTG team
* Kernel srcrev updates for all the BSPs - Bruce, Nitin & IoTG team
* Microcode commits - Nitin
* Machine setup tool commits - Nitin
* Follow the release process. Includes making BSP tar balls, Publishing of the BSPs, YP compatible certification, Release Notes - Michael + other
* Important bugs to fix before the release:
** bug #6162 - Bruce
=== Related reference material === 
* Yocto Release Engineering
* Meta-intel Release Process
Meta-intel Test Report for Yocto 1.4 201304271

=Testing data=
 
 Test type: On-demand meta-intel test
 Branch: dylan
 Milestone: 1.4 M6
 poky commit: 789b2b7e0cca404ff8ba8ed5ba823d215e6ba5b4
 poky commit date: Thu Apr 18 22:02:26 2013 +0100
 meta-intel commit:6147ba0e962c3d7ba28b53b9b930f1bed5833c90 
=Summary Report=
	
=Detailed Report=
===NUC: core-image-sato-sdk===
Status
Bugs
Agenda
===Emenlow: core-image-sato-sdk===
Status
Bugs
Agenda
===Sugarbay: core-image-sato-sdk===
Status
Bugs
Agenda
===Jasperforest: core-image-lsb-sdk===
Status
Bugs
Agenda
===Crownbay: core-image-sato-sdk-noemgd===
Status
Bugs
Agenda
===FRI2: core-image-sato-sdk===
Status
Bugs
Agenda
Meta intel 6c1c01392d91f512e2949ad1d57a75a8077478ba

< Back
Ran on a intel-corei7-64_cherryhill and compared with commit f4f1d206f4ebafcde18c96c88a1bfc4ab7b0c119
{| class="wikitable"
|+Results
|- style="background-color:#F0F8FC; padding:10px;"
|Package Name ||Tests ran ||Passed ||Failed ||Passrate ||Last Passrate ||Run difference
 |-
 |intel-corei7-64_cherryhill ||55 ||style="background-color:#C4FF33;" |54 ||style="background-color:#F78D72;" |1 ||style="background-color:#C4FF33;"|98.0% ||style="background-color:#C4FF33;"|98.0% ||style="background-color:#C4FF33;"|NoResults for intel-corei7-64_cherryhill meta_intel runtime 2016-05-05:********************************Tests that failed now and worked last time: 0Tests that passed now and and failed last time: 0Tests that were skipped now and worked last time: 0Tests that were skipped last time and worked now: 0Tests that failed now: 1testcase-1096
Meta intel ea562de57590c966cd5a75fda8defecd397e6436

< Back
{| class="wikitable"
|+Results
|- style="background-color:#F0F8FC; padding:10px;"
|Package Name ||Tests ran ||Passed ||Failed ||Passrate ||Last Passrate ||Run difference
 |-
 |intel-corei7-64_minnowmax ||58 ||style="background-color:#C4FF33;" |57 ||style="background-color:#F78D72;" |1 ||style="background-color:#C4FF33;"|98.0 ||style="background-color:#C4FF33;"|98.0 ||style="background-color:#C4FF33;"|No
 |-
 |intel-corei7-64-lsb_nuc ||58 ||style="background-color:#C4FF33;" |54 ||style="background-color:#F78D72;" |4 ||style="background-color:#C4FF33;"|93.0 ||style="background-color:#C4FF33;"|93.0 ||style="background-color:#C4FF33;"|No
 |-
 |intel-corei7-64_nuc ||58 ||style="background-color:#C4FF33;" |58 ||style="background-color:#C4FF33;" |0 ||style="background-color:#C4FF33;"|100.0 ||style="background-color:#C4FF33;"|100.0 ||style="background-color:#C4FF33;"|No
 |-
 |intel-core2-32_minnowmax ||58 ||style="background-color:#C4FF33;" |57 ||style="background-color:#F78D72;" |1 ||style="background-color:#C4FF33;"|98.0 ||style="background-color:#C4FF33;"|98.0 ||style="background-color:#C4FF33;"|No
 |-
 |intel-core2-32-lsb_minnowmax ||58 ||style="background-color:#C4FF33;" |54 ||style="background-color:#F78D72;" |4 ||style="background-color:#C4FF33;"|93.0 ||style="background-color:#C4FF33;"|93.0 ||style="background-color:#C4FF33;"|No
 |-
 |intel-corei7-64-lsb_minnowmax ||58 ||style="background-color:#C4FF33;" |54 ||style="background-color:#F78D72;" |4 ||style="background-color:#C4FF33;"|93.0 ||style="background-color:#C4FF33;"|93.0 ||style="background-color:#C4FF33;"|No
 |-
 |intel-corei7-64-lsb_nuc ||58 ||style="background-color:#C4FF33;" |54 ||style="background-color:#F78D72;" |4 ||style="background-color:#C4FF33;"|93.0 ||style="background-color:#C4FF33;"|93.0 ||style="background-color:#C4FF33;"|No
 |-
 |intel-corei7-64_cherrytrail ||58 ||style="background-color:#C4FF33;" |57 ||style="background-color:#F78D72;" |1 ||style="background-color:#C4FF33;"|98.0 ||style="background-color:#C4FF33;"|98.0 ||style="background-color:#C4FF33;"|No
Meta intel f9ea480e6c26fea46c3011c4e9d0e2de3d5c81b4

< Back
{| class="wikitable"
|+Results
|- style="background-color:#F0F8FC; padding:10px;"
|Package Name ||Tests ran ||Passed ||Failed ||Passrate ||Last Passrate ||Run difference
|-
|intel-corei7-64_nuc ||57 ||style="background-color:#C4FF33;" |57 ||style="background-color:#C4FF33;" |0 ||style="background-color:#C4FF33;"|100.0 ||style="background-color:#C4FF33;"|100.0 ||style="background-color:#C4FF33;"|No
Meta intel fido

< Back
{| class="wikitable"
|+Results
|- style="background-color:#F0F8FC; padding:10px;"
|Package Name ||Tests ran ||Passed ||Failed ||Passrate ||Last Passrate ||Run difference
|-
|intel-corei7-64 ||57 ||style="background-color:#C4FF33;" |56 ||style="background-color:#C4FF33;" |1 ||style="background-color:#C4FF33;"|98.0 ||style="background-color:#C4FF33;"|100.0 ||style="background-color:#F78D72;"|YesResults for intel-corei7-64 meta_intel runtime 2015-06-15:********************************Tests that failed now and worked last time: 1testcase-test_parselogsTests that passed now and and failed last time: 0Tests that were skipped now and worked last time: 0Tests that were skipped last time and worked now: 0
|-
|intel-core2-32 ||57 ||style="background-color:#C4FF33;" |56 ||style="background-color:#C4FF33;" |1 ||style="background-color:#C4FF33;"|98.0 ||style="background-color:#C4FF33;"|98.0 ||style="background-color:#C4FF33;"|No
|-
|intel-corei7-64 ||57 ||style="background-color:#C4FF33;" |57 ||style="background-color:#C4FF33;" |0 ||style="background-color:#C4FF33;"|100.0 ||style="background-color:#C4FF33;"|98.0 ||style="background-color:#F78D72;"|YesResults for intel-corei7-64 meta_intel runtime 2015-06-15:********************************Tests that failed now and worked last time: 0Tests that passed now and and failed last time: 1testcase-test_parselogsTests that were skipped now and worked last time: 0Tests that were skipped last time and worked now: 0
MicroYocto

Some community members and Yocto Project maintainers have been working on a Linux-based kernel for memory-constrained embedded systems. It has been referred to in conference presentations as "micro-yocto", although the final name has not yet been decided. 
This feature layer, which is built as a variation from the Poky-Tiny distro feature layer, is currently available as a special BSP for the Intel Galileo board, but it will be available soon as its own feature layer that can be used with other appropriate BSPs.
As a community-built feature, microYocto is supported by the Yocto Project community and can be discussed on the mailing lists or IRC channels. 
For a brief overview of microYocto and its capabilities, see these slides from Tom Zanussi's presentation at ELC 2014. You can also listen to the audio from this presentation.
Before you run through the instructions for building and booting microYocto, run through the Yocto Project Quick Start Guide. This ensures that you have a functional setup for building microYocto.
Once you've successfully built an image as described in the Quick Start Guide, you can download the following instructions for building microYocto for the Galileo. This document should be all you need to get started:
 $ wget https://github.com/tzanussi/meta/galileo/raw/daisy/meta-galileo/README
For specific questions, contact Jefro directly.
MinnowMax board Serial video connection guide

==Two-Way Serial Communication with MinnnowBoard Max in Linux==
This tutorial explains how to set up two-way serial communication between a MinnnowBoard Max and
a host computer running a Linux operating system. These instructions are based upon Ubuntu Linux
and the serial terminal application ‘screen’, but other Linux environments and serial terminal
applications with comparable functionality are also available to perform the same tasks.
== Connection between Host and Target ==
== Serial Cable to USB ==
1. You must have the appropriate USB 6 pin header cable to connect to the MinnowBoard Max. This
is a USB to 3.3V TTL Header. You can purchase on the web by searching for the following part
number: SS-TTL3VT . The cost is approximately $20 USD.
== To install screen ==
2. With root user permissions run the Advanced Packaging Tool to download and install the screen by
running the following command from a terminal:
sudo apt-get install screen
3. The 6 pin header on the MinnowBoard Max serves as the serial port output:
• Connect the other end (USB Type A ) to the USB port of your computer.
• Note: Pin 1 of the Header is closest to the SATA connector. Pin 1 of the SS-TTL3VT cable is the Black lead wire.
If you are running Linux in a virtual machine be sure that the virtual machine USB connection
is active.
Run the dmesg command from a terminal to determine which tty is created (typically
ttyUSB0).
Look for the FT230x Basic UART.
Find the line that says FTDI USB Serial Device Converter now attached to ttyUSBX,
where X is the assigned number.
== To start screen for MinnnowBoard Max serial communication purposes ==
1. Make sure to have root user permission and execute the command:
 sudo screen /dev/ttyUSBX 115200
2. Replace the X of USBX with the actual assigned tty number found during the previous step.
The 115200 indicates the baud rate for the serial data transfer.
--Juan Ramos (talk) 11:03, 31 October 2016 (PDT)
Minnow Bug Triage

= Goal =
The output of the bug triage meeting should be that all bugs have an owner, a target milestone, and a priority.
Prior to the meeting, each Product Owner should review their Weekly New and High Bugs and be ready with any opens. An example open would be a bug that may need to change Products.
= Agenda =
* Opens
** Collect opens
** Discuss opens
* Review Queries
** State number and owner
** Owner makes any modifications
** Assign owner, target milestone, and priority.
Note: for Yocto Project bugs go to: Bug Triage
= Bug Criteria =
* Priority-Severity
** High: Two Week
** Medium+: Milestone
** Medium: Nice to have for milestone, must have for release
= MinnowBoard Bug Triage Searches =
== Non-Prioritized Bugs ==
== NEEDINFO ==
== MinnowBoard-MAX Open Bugs ==
== MinnowBoard-MAX Closed Bugs ==
Missing Tests

A list I had gathered earlier and slightly updated recently (should be double-checked) - PaulEggleton (talk) 19:56, 20 November 2017 (PST)
* recently added devtool/recipetool functionality
* bitbake picking up file changes while memory resident (esp. adding files to empty dirs / creating dirs in search path)
* bitbake-diffsigs
* locked sigs
* PACKAGE_EXCLUDE / NO_RECOMMENDATIONS / BAD_RECOMMENDATIONS
* sstate (bug 5839, 2082, 6006, 6855)
* kernel config usage (config fragments, defconfig, etc.)
* improved buildhistory tests
* menuconfig (bug 5876)
* archiver
* image / SDK manifest contents
* read-only-rootfs
* complementary packages
* file ownership and permissions under pseudo
* useradd.bbclass + chown
* incremental image generation needs to be extended to IPK
* update-alternatives.bbclass
* full tests of recipe selection (layer priority, PREFERRED_VERSION, PREFERRED_PROVIDER, DEFAULT_PREFERENCE, etc.)
* synthetic test of build system, dependency handling?
* package QA checks
* IMAGE_LINGUAS
* KERNEL_MODULE_AUTOLOAD
* end-to-end test of licensing features
* extrausers / EXTRA_USERS_PARAMS
* create-pull-request/send-pull-request
* send-error-report / report-error.bbclass
* terminal support?