Skip to content
Embedded Linux distribution optimized for product development (based on OE/Yocto)
Branch: master
Clone or download
Latest commit d190768 May 10, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
conf site.conf: Dont enable sdl in qemu explicitly Apr 6, 2019
docs update bootstrap instructions Feb 18, 2019
sources Layer Updates: sources/meta-browser sources/meta-freescale sources/me… May 10, 2019
.gitignore gitignore: Ignore whole images/ dir Jan 10, 2019
.gitmodules gitmodules: Do not sue shallow clones by default May 2, 2019
COPYING.MIT
README.md note that submodules are shallow clones Mar 28, 2019
envsetup.sh fix: some environment may not have $UID $GID Mar 27, 2019
imx6qdl-variscite-som-envsetup.sh Add imx6qdl-variscite-som to env Sep 24, 2018
imx6ul-var-dart-envsetup.sh export MACHINE in files that are not soft links Aug 31, 2018
imx6ulevk-envsetup.sh Add freescale layers and imx6ulevk to envsetup Sep 24, 2018
imx7s-warp-envsetup.sh imx7s-warp-envsetup.sh: create envsetup for WaRP7 Feb 8, 2019
local.sh.example switch to yoedistro docker image in comments/examples Oct 17, 2018
minnowboard-max-envsetup.sh export MACHINE in files that are not soft links Aug 31, 2018
odroid-c2-envsetup.sh envsetup.sh: Add odroid-c2 and odroid-xu4 Sep 24, 2018
odroid-xu4-envsetup.sh envsetup.sh: Add odroid-c2 and odroid-xu4 Sep 24, 2018
overo-envsetup.sh export MACHINE in files that are not soft links Aug 31, 2018
qemuarm-envsetup.sh envsetups: Add logic to detect machine from envscript name Aug 26, 2018
qemuarm64-envsetup.sh envsetups: Add logic to detect machine from envscript name Aug 26, 2018
qemuarmv5-envsetup.sh qemuarmv5-envsetup.sh: Add setup for armv5te qemu Mar 15, 2019
qemumips-envsetup.sh envsetups: Add logic to detect machine from envscript name Aug 26, 2018
qemumips64-envsetup.sh envsetups: Add logic to detect machine from envscript name Aug 26, 2018
qemuppc-envsetup.sh envsetups: Add logic to detect machine from envscript name Aug 26, 2018
qemuriscv64-envsetup.sh Add support for qemuriscv64 in envscript Aug 29, 2018
qemux86-64-envsetup.sh envsetups: Add logic to detect machine from envscript name Aug 26, 2018
qemux86-envsetup.sh envsetups: Add logic to detect machine from envscript name Aug 26, 2018
raspberrypi2-envsetup.sh envsetups: Add logic to detect machine from envscript name Aug 26, 2018
raspberrypi3-64-envsetup.sh envsetups: Add logic to detect machine from envscript name Aug 26, 2018
raspberrypi3-envsetup.sh envsetups: Add logic to detect machine from envscript name Aug 26, 2018
sama5d27-som1-ek-sd-envsetup.sh make SAMBA scripts a little more consistent Apr 15, 2019

README.md

Yoe Embedded Linux Distribution

Yoe is an Embedded Linux Distribution optimized for product development. It is built on Yocto and OpenEmbedded with a focus on simplicity. This distribution does not end at demo images but rather begins there.

Example

This following is example of building and installing a linux system from scratch on a Raspberry PI 3:

Install Pre-requisites

Install docker on host distribution

  • debian-like systems - sudo apt install docker
  • RPM based systems - sudo dnf install docker
  • Archlinux based systems - sudo pacman -S docker

Workspace Setup

  1. git clone --recurse-submodules -j8 -b master git://github.com/YoeDistro/yoe-distro.git yoe
  2. cd yoe
  3. . ./raspberrypi3-64-envsetup.sh
  4. yoe_setup
  5. bitbake yoe-simple-image
  6. insert SD card
  7. lsblk (note sd card device, and substitute for /dev/sdX below)
  8. yoe_install_image /dev/sdX yoe-simple-image
  9. optional: configure console for serial port
  10. sudo eject /dev/sdX
  11. Install SD card in a Raspberry PI and enjoy your new image

Detailed documentation

Vision

There are many Embedded Linux distribution built on top of OpenEmbedded/Yocto. There is the Poky reference distribution. Most SOC and SOM vendors provide a Yocto variant that supports their products (often put together with repo). While these all provide good ways to build demo images, we feel something slightly different is needed for product development. Thus, the following goals:

  1. simple: directory layout is logical so it is easy to find things, and tooling is as simple as possible. Emphasis is on logical organization, minimal magic, and good tooling where it makes sense. We try to minimize uneeded indirection or abstraction unless it really adds value.
  2. modern: generate a modern Linux root filesystem using the latest technologies.
  3. broad platform support: support a range of single board computers (SBC), system on chips (SoC), and system on modules (SOM). You should not have to use a different build system for every SBC/SOC/SOM you might choose to use in your products. Rather, one build system should easily support building images for a number of different targets in one build tree. Most companies support multiple products with SOCs from multiple vendors, thus the build system should be centered around the user's products and software.
  4. repeatable: easy to lock down subprojects (layers) to known versions for repeatable builds
  5. extendable: simple to modify and add your own custom software, scripts and tooling. The focus is not on hiding or abstracting Yocto functionality, but rather provider simpler and clearer ways to use it.
  6. maintainable: product lifecycles run for many years, so we need a solution where we can build images on a number of different hosts as time marches on. We achieve this through a simple and transparent docker wrapper that contains all the host dependencies needed. This wrapper is invisible (the file system still lives on the host), and is optional if you choose not to use it.
  7. transparent: we try to use industry standard tools (git, bitbake, etc) where possible and not invent a lot of new tooling that needs to be learned to use the system. As an example, much of the tooling (envsetup.sh) are simple bash functions and are easy to learn from. Using Yoe will teach you about Yocto.
  8. minimal: Embedded Linux images can quickly become bloated so we support technologies like musl libc, opkg package manager, etc. where appropriate.

Supported Machines

See the <machine>-envsetup.sh files for examples of machines we regularly test with.

There is also machine specific documentation available.

Additional machines can be added by including appropriate BSP layers.

Using

envsetup.sh

This is where all the magic happens. In general, this build system must be run in a bash shell. To set up the environment, source the following file:

. ./<machine>-envsetup.sh

Or, you can export a MACHINE environment variable, and then source envsetup.sh.

This file will create a bunch of functions in the environment prefixed with yoe_ that can be executed. Type yoe_ to see them.

directories and key files

  • build: temporary directory where build actually takes place
  • conf: configuration files for the build
  • sources: various sources used for the build. The entries in this directory are git submodules. Note, by default, submodules are shallow clones. If you need the the full git history of a submodule, then run git fetch --unshallow in the submodule directory.
  • downloads: contains files that are downloaded by various recipes during builds.
  • tools: utility scripts
  • localconfig.sh: file created by envsetup.sh that contains directory specific variables based on the build system location.
  • local.sh: can be used to customize MACHINE, and other variables

building for another machine

  • export MACHINE=[my machine]
  • bitbake [recipe name]

Layer management

Adding rocko branch of meta-altera layer to layer mix:

yoe_add_layer https://github.com/kraj/meta-altera rocko

Remove meta-altera:

yoe_remove_layer meta-altera

customizing settings

conf/local.conf contains settings that are commonly modified such as parallel build options.

starting a local feed server

Sometimes you want to install packages you build on the target system without building and re-installing the entire rootfs. This can be done using a feed server.

This advantage of a feed server versus scp'ing opkg files to the target and installing manually is that dependencies will automatically get installed. This mechanism is very useful for packages that are only needed occasionally during development (gdb, screen, strace, iperf, etc).

updating the submodules to the latest

Assuming you have a recent version of git, you can make use of the branch values specified in .gitmodules to update each submodule branch to the HEAD of the specified branch:

git submodule update --remote

License

This build system is licensed under the MIT license which is the same license as oe-core, etc. See COPYING.MIT

Contributions are welcome: please open issues or pull requests.

You can’t perform that action at this time.